Re: linking in private non-Framework libraries
Re: linking in private non-Framework libraries
- Subject: Re: linking in private non-Framework libraries
- From: Sherm Pendley <email@hidden>
- Date: Mon, 30 Sep 2002 13:52:18 -0400
On Monday, September 30, 2002, at 02:20 AM, Drew McCormack wrote:
If that doesn't work, you could try moving the dylibs out of the
directory they are in, so they are not in the library path anymore, and
then doing a clean build.
That, or deleting the dylibs entirely, will solve the problem.
The problem is that GCC, if it finds both dynamic and static libraries,
will link against the former. There's a linker flag ("-static") that
will prevent it from linking against any dynamic libraries, but I've
found this to be virtually useless, as it prevents linking against *any*
dynamic libraries - including libcrt0.o, the C runtime. I don't know of
a linker flag that will tell it to prefer the static version of a
particular library, while still linking against other dynamic libraries.
If the library you're using (Berkeley DB, wasn't it?) uses the
traditional autoconf-generated configure script (./configure; make; sudo
make install), you should be able to use the "--disable-shared" option
to "./configure" to build only the static version. Conversely,
"--disable-static" should build only the shared library. As a bonus,
using either option will reduce the time needed to build the library.
Autoconf configure scripts generally have quite a few such options;
"./configure --help" will generate a list of valid options.
HTH!
sherm--
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.