Re: How can I use a .dylib created in Xcode in my gcc-compiled program?
Re: How can I use a .dylib created in Xcode in my gcc-compiled program?
- Subject: Re: How can I use a .dylib created in Xcode in my gcc-compiled program?
- From: Terry Lambert <email@hidden>
- Date: Mon, 15 Oct 2007 21:30:55 -0700
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)
or
g++ main.cpp -L. -lmine -o run
In both cases it compiles (what is the difference??), but I get the
following error when I try to execute the program:
$ ./run
dyld: Library not loaded: /usr/local/lib/libmine.dylib
Referenced from: /Users/milford/program/./run
Reason: image not found
Trace/BPT trap
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.
Use the command:
otool -L run
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):
cp /usr/lib/libSystem.B.dylib /tmp
otool -D /tmp/libSystem.B.dylib
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:
/tmp/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib
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;
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>
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):
#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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden