I am using setenv to set DYLD_LIBRARY_PATH so when I do a dlopen() it will have the correct paths to find my .dylib, but when I do the dlopen() it doesn't seem to search the paths that I added to DYLD_LIBRARY_PATH.
From what I can gather my changes to DYLD_LIBRARY_PATH won't take effect until a re-execute my process happens. Is this correct?
Also if that is correct, is there a way to set DYLD_LIBRARY_PATH and having my changes work with out doing a reset of my process.
Oh yeah I writing this code on MAC OSX.
Thanks in advance.
I don't know about Mac OS, but on Linux, the loader reads the value of getenv("LD_LIBRARY_PATH") once, and saves it away, long before the first instruction of your executable runs. Subsequent modification of LD_LIBRARY_PATH by the program only affects any children it execve()s, but not the process itself. I imagine it's similar on Mac OS.
The usual way around this is to either re-execve the proces (Java does this), or to use a shell wrapper which sets the environment and then exec's the real binary (Firefox does that).
There might be a Mac OS specific way to update the library search path, though Google doesn't seem to find any matches. I am pretty sure there isn't any such mechanism on Linux.
The answer to my question is no you can't use setenv without doing a re-execute of the process on LD_LIBRARY_PATH for the environmental variable to take an effect on dlopen.
I found out that you should use #exectuable_path, #loader_path, or #rpath as an install name path on my .dylb is this way you can do a relative path search on your .dylibs from dlopen.
Related
I've got a very curious error to share regarding Xcode localization process. I will try to share as much detail as legally possible.
From Xcode, I am trying to export an XLIFF file to send to our translators, via "Editor > Export for Localizations". However, this immediately throws error with the message:
The operation couldn't be completed. Argument list too long
This is indeed confusing, as I cannot find a more verbose log anywhere (I have already tried checking my Console.app). So, I spent quite a few time googling – to no avail. I couldn't find similar case like this. The error itself happens only when I am trying to export for localization. I can build and run the app just fine.
Facts
~ $ xcodebuild -version
Xcode 8.2
Build version 8C38
~ $ xcode-select -version
xcode-select version 2347.
~ $ echo $PATH
/Users/david.christiandy/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/david.christiandy/arctools/arcanist/bin:/usr/local/go/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
I am using Xcode 8.2 on macOS Sierra 10.12.5.
The error happens only when I try exporting from localization. This is also true when I run the localization process via xcodebuild -exportLocalizations.
I can build and run the app just fine. (I believe) there's no problem with my header search paths.
Attempts
Thought there was something wrong in the code, so I tried to run the export process (via xcodebuild command) in a CI. Somehow, it's working. For the record, I am using Bitrise CI with the same stack as my system (Xcode 8.2.x, macOS 10.12)
Asked colleagues to run export process on their machines, and they have the same error.
This leads me to think that there must be something wrong with the configuration. So I made a standalone project to confirm that the export process fails consistently. Turns out, it works just fine!
So, the hypothesis I got currently is:
There's probably something wrong in the code, and
There might be tools/software (that most of our iOS engineers installed) that might contribute to the error (since the CI completes just fine).
I don't know why the CI can run the export process just fine, and I don't know when it might suddenly stop functioning (just like our local machines).
Appreciate any help on this matter. Thank you!
I also asked this question on Apple developer forums, here is the link: https://forums.developer.apple.com/thread/86762
“Argument list too long” sounds like E2BIG, which you get when you try to run a child process with a huge argument list (I believe the current limit is 256 KiB). I suspect that Export for Localizations is running some sort of command line tool to do that work (probably the extractLocStrings tool, which you’ll find lurking within Xcode’s app bundle) and passing it full paths to each of the files in your project. Depending on how many files you have and how long those paths are, it’s easy to run into problems like this.
One of the ‘fun’ things about bugs like this is that they are dependent on where you place your project. Things might work if the project is at the top of your home directory but fail if it’s nested deep inside a subdirectory.
That also suggests a potential workaround, namely, to move your project further up in the directory hierarchy.
Finally, you should definitely file a bug about this. I believe we’ve seen this before (r. 30703294) but your report will help reinforce that this is causing problems for developers in the field. Please post your bug number, just for the record.
Several days ago before I read this answer, I managed to get the export working by deleting some folders via Xcode (remove references only). Initially I suspected that there's an invalid format within the folders that I deleted, but when I tried deleting other folders, the export process works just fine.
I also tried exporting strings using Xcode 9, and I didn't encounter the problem. So hopefully this bug is only for Xcode 8.3.3 and below.
I'm trying to profile app startup after moving from static libraries to frameworks. We have 30 or so frameworks (fyi: cocoapods) so I want to check that it's not affecting performance. Anecdotal testing in the team says that it isn't, but I would like some numbers as well!
I've added the environment variables DYLD_PRINT_STATISTICS and DYLD_PRINT_LIBRARIES to see what the linker is doing, but all the output I get is from the DYLD_PRINT_LIBRARIES variable. I can see that the frameworks are loading correctly, but get no statistics from them.
I've tried restarting the device to make sure that the frameworks aren't in memory already but that hasn't helped.
Any other suggestions as to why I'm not getting any output from DYLD_PRINT_STATISTICS?
Looks like you can do it on device if you enable both environment variables in your scheme:
DYLD_PRINT_APIS = YES
DYLD_PRINT_STATISTICS = YES
Reference:
https://github.com/artsy/eigen/issues/586#issuecomment-118606377
While other flags, like DYLD_PRINT_BINDINGS work fine on the device, DYLD_PRINT_STATISTICS only seems to work on the simulator (for me, iOS 9.0).
In this (possibly unrelated) version of dyld.cpp, from osx 10.10.5 there doesn't seem to be any obvious exclusion of DYLD_PRINT_STATISTICS for devices, although there are conditionally compiled TARGET_IPHONE_SIMULATORs sprinkled throughout the code.
I guess it's a bug.
I am completely new to CUDA and C. My eventual goal is to adapt a FORTRAN program for CUDA. For now, I am having trouble getting a simple "Hello world" program to run.
I have been able to compile using nvcc hello_test.cu --machine32 which creates an executable. However when I try to run the .exe, I get a System Error message stating:
The program can't start because cudart32_32_9.dll is missing from your computer. Try reinstalling the program to fix this problem
I imagine I haven't added the path to this file (which I can find in "C:\ProgramData\NVIDIA Corporation\NVIDIA GPU Computing SDK 4.2\C\common\bin\"); but I don't know how to add the path. Any help would be appreciated.
You can go several routes. Either just make a copy of the DLL and put it in the same directory as your executable.
Or you can add the path you mentioned in the PATH environment variable of Windows. Then it should be able to find the DLL.
I need to debug the startup for an ios application on an actual device... and by start up I mean the very first instruction that is is executed when the OS hands control over to the app. Not "main". Also, this application doesn't have any symbols (ie. the debug information isn't available.. yet). I don't care if I have to debug at the CPU instruction level. I know how to do that (done it for over 30 years). I want the debugger to stop when control is about to transfer to the app. When I use the Attach|by Name command and run, it just says "Finished running".
Oh, and this application was not built in XCode. It is, however an application I built, signed and provisioned and moved to the device. The application does run since I can see the console output. Just in case you're thinking I'm some hacker trying to debug someone's application.
How's that for a tall order? I'll bet nobody can answer this... I've not been able to find any information on how I could do this with an XCode-built project. I wonder if it is simply not possible or "allowed" by the Apple overlords?
What do you say, Stack Overflow gods?
UPDATE: I should clarify something. This application is not built with any commercially available or open-source tool. I work with a tools vendor creating compilers, frameworks, and IDEs. IOW, you cannot get this tool... yet. In the process of bootstrapping a new tool chain, one regularly must resort to some very low-level raw debugging. Especially if there are bugs in the code generated by the tools.
I'm going to answer my own question because I think I've stumbled upon a solution. If anyone has anything more elegant and simple than this, please answer as well. On to the steps:
Starting with a raw monolithic iOS executable (not a bundled .app, but the actual binary mach-o file that is the machine code).
Create a new like-named empty Xcode project. Build and run it on the device.
Locate the output bundle's .app folder.
Copy the above raw iOS executable over the existing one in the .app bundle's folder.
The application will now have an invalid signature and cannot be deployed and run.
Run codesign against the app bundle (you can find out the command-line by running xcodebuild on the above Xcode project).
In the bundle's .app folder, run otool -h -l on the binary image. Locate the LC_UNIXTHREAD load command and find the value associated with the 'pc' register. This is address where the os loader will jump to your application. If this address is odd, then these are Thumb instructions otherwise it will be ARM (I think that's how it works).
Add a symbolic breakpoint (I used GDB instead of LLDB) and enter the address as '*0x00001234' as the symbol.
Select Product|Perform Action|Run Without Building.
Assuming that GDB is able to evaluate the breakpoint expression and set the break point, and you've selected Product|Debug Workflow|Show Disassembly When Debugging, the process should break at the very first instruction to be executed in the application.
You can now single step the instructions and use the GDB console to get/set register values.
Your question does not make sense - main is the entry point into the application. It is the first code that should be encountered, unless possibly you have initialize() overridden for some classes (but even then I think main would get hit before the runtime).
I think you are seeing some kind of odd error on launch and you think you want to set a breakpoint on entry to catch it, but far more likely what would help you is to describe the problem on launch and let one of the 4000 people who have seen and fixed the same crash help you...
However, if you really want to use GDB to break on an application with no symbols (but that you launch from XCode) you can have GDB break on an assembly address as per:
How to break on assembly instruction at a given address in gdb?
To find the address of main (or other methods) you can use tool or atos, some examples in this question:
Matching up offsets in iOS crash dump to disassembled binary
ADDITION:
If for some reason XCode cannot launch your application for debugging, you could also jailbreak and install GDB on the device itself which would give complete control over debugging. If XCode can launch you application I see no reason why being able to break at an arbitrary memory address does not give you the ability you seek...
One solution for applications with webviews is to run them in the iOS Simulator, and connect to that with the remote-debugger in macOS Safari. This is off-topic but maybe the one or other could benefit.
http://hiediutley.com/2011/11/22/debugging-ios-apps-using-safari-web-inspector/
Or use NetCat for iOS... not the most perfect solution, but at least you see what's going on.
I'm very inexperienced with Linux and the terminal, but I'm trying to learn. I've also never included an external library before. Now I need to include the Boost.Asio library in a program being developed in Ubuntu with G++.
Could someone very kindly and very carefully explain how to go about this, from the beginning?
EDIT:
Expanding on the original question: if I need to send this code to someone else for them to run it on a completely separate machine but in the same environment, how do I take that into account? If this whole process involves literally placing library files into the same folder as the code, do I just send those library files along with the .cpp to this other person?
You have mentioned you are using Ubuntu, so the simplest way to use boost is to first install libboost-all-dev package (from synaptic), which will install everything for you including those that needed to be compiled. Then you just need to use g++ in the usual way.
Please note that whether the version is what you want, if not, you may want to install it yourself. On the other hand, boost is mostly header only library, so you only need to extract the files (right click in Ubuntu...) to a folder and link to it while compiling:
g++ hello_world.cpp -I boost_1_49_0/boost
where the last one specify the path for compiler to find the boost headers (please use absolute path).
If you want to send your program to others, dont copy only some boost files, it does not work because of the dependence. Ask them to install the same environment as you while is easy (just unzip a file...).
I don't know about your specific IDE, or about Boost.Asio specifically, but in general:
Whenever you need to link to a library, there is a file named similar to lib???.a, which you need. You need to pass the -l??? flag to g++ to link to the file.
(I'm not too familiar with the details myself, so there might be other file formats and whatnot too...)
Regarding the edit:
The "right" way would be to just have them download the library themselves, and just pass -l??? to their linker. Including Boost in your source code will make it huge, and for no good reason... it's not like you include the STL in your code, after all.
You don't include the library, but instead you declare a dependency on it. Eg. consider you use autoconf and automake then you would add AX_BOOST_BASE1 to require boost and AX_BOOST_ASIO to require the ASIO libraries. In your Makefile.am file(s) you use BOOST_CPPFLAGS and BOOST_LDFLAGS macros and rely on the ./configure to set them properly. Then whoever consumes your code will have to run the well know ./configure script which will analyze the environment for the location of boost and setup appropriate values in the build environment so that the make succeeds.
Well at least this is the theory. In practice there is a reason the whole thing is better known as autohell. Alternatives exists, like CMake or boost's own bjam. But the synopsis is always the same: you declare the dependency in your build configuration and the destination location that consumes you product has to satisfy the requirement (meaning it has to download/install the required version of boost, in your case). Otherwise you enter into the business of distributing binaries and this is frowned with problems due to richness of platforms/architectures/distributions your application is expected to be deployed in.
Obviously if you use a different build system, like ANT, then you should refer to that build system documentation on how to declare the requirement for boost.
1: ax_boost.m4 is not the only boost detecting m4 library, there are other out there, but is the one documented on the GNU autoconf list of macros