site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com or g++ main.cpp -L. -lmine -o run $ ./run dyld: Library not loaded: /usr/local/lib/libmine.dylib Referenced from: /Users/milford/program/./run Reason: image not found Trace/BPT trap Use the command: otool -L run cp /usr/lib/libSystem.B.dylib /tmp otool -D /tmp/libSystem.B.dylib /tmp/libSystem.B.dylib: /usr/lib/libSystem.B.dylib extern "C" { ... prototypes ... } And here is a FAQ for how to use it in great detail: <http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html> #include <sys/cdefs.h> __BEGIN_DECLS ... prototypes ... __END_DECLS -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Oct 15, 2007, at 7:06 PM, Milford Brimdash wrote: Boris Remizov said: Hmmm...> Try to play with extern "C" directive before your func (). That is only part of the solution. For example, if I have a library I made named libmine.dylib, I can compile my program in two ways: g++ main.cpp libmine.dylib -o run (assuming libmine.dylib is in the same directory) In both cases it compiles (what is the difference??), but I get the following error when I try to execute the program: I don't think you've installed a copy of the library in /usr/local/lib/ libmine.dylib. When you link against a dynamic library, the library location becomes known to your program based on its expected install location. To find out where your binary expects to find its libraries, and install them where they are supposed to be. Alternately, read the dyld manual page and set the DYLD_LIBRARY_PATH environment variable to make it search where your library lives (see the manual page for more detail). If you can't/won't install the library in its intended location set at compile time, you can tell it another location (the place where it really lives) using ld options, or you can specify the ld option - headerpad_max_install_names, and use install_name_tool to change your binary to point to where the library actually lives. You can also look at the LC_ID_DYLIB section in the library, which is set by the -install_name linker option when creating the library; for example, for libSystem, we copy it so that the only way it could know its install location was if it was in the library (this will prove what we think we are proving): And this is the output, indicating that it knows where it's supposed to be installed, and programs linked against the file, no matter where it is at the time of the link, are going to look there, unless you use one of the options above to change that: Another thing I've noticed...if I compile a .dylib in Xcode with the C compiler, I can call a function from the library in a separate program, but if I recompile the .dylib using the C++ compiler (no changes to the code though!) I can't even compile and link the program that uses the library. As others have pointed out, if this is intended to be a C library, then you will not want to compile it with g++ because of symbol decoration. You can either make sure there is a C prototype in scope at the time you compile it, and wrap it with; You can also use the macros built into <sys/cdefs.h> to do the same thing (and avoid scoping when you shouldn't be when compiling with the vanilla C compiler): This email sent to site_archiver@lists.apple.com