[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compile on MacOS
Andrea -XFox- Govoni
Re: Compile on MacOS
Tue, 08 Nov 2005 11:34:27 +0100
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; it-IT; rv:1.8b) Gecko/20050217
Thomas Dickey ha scritto:
>> I downloaded ncurses-5.5.tar.gz from
>> and I didn't apply any patch.
>> Any clue about where those undefined symbols comes from?
> They come from an existing shared library for ncurses - I'm not
> developing on MacOS, so I can only report secondhand information here. I
> don't know
> whether there's a nice way, e.g., an rpath option that can be added to
> $LDFLAGS to make it pick up the "right" library. So the libncursesw has
> no counterpart, no conflicts.
According to file PROBLEMS of openssl-0.9.8a source code distribution
, it's a misfeature in Apple's ld:
% ld -v
Apple Computer, Inc. version cctools-590.obj~12
PROBLEMS file reports:
"* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
NOTE: The problem described here only applies when OpenSSL isn't
built with shared library support (i.e. without the "shared"
configuration option). If you build with shared library support,
you will have no problems as long as you set up DYLD_LIBRARY_PATH
properly at all times.
This is really a misfeature in ld, which seems to look for .dylib
libraries along the whole library path before it bothers looking for .a
libraries. This means that -L switches won't matter unless OpenSSL is
built with shared library support.
The workaround may be to change the following lines in apps/Makefile and
It's possible that something similar is needed for shared library
support as well. That hasn't been well tested yet.
Another solution that many seem to recommend is to move the libraries
/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
directory, build and install OpenSSL and anything that depends on your
build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
original places. Note that the version numbers on those two libraries
may differ on your machine.
As long as Apple doesn't fix the problem with ld, this problem building
OpenSSL will remain as is.
Curiously, ld main on the -lx flag says:
"-lx This option is an abbreviation for the library name `libx.a',
where x is a string. If -dynamic is specified the abbreviation
for the library name is first search as `libx.dylib' and then
`libx.a' is searched for. ld searches for libraries first in
any directories specified with -L options, then in the standard
directories /lib, /usr/lib, and /usr/local/lib. A library is
searched when its name is encountered, so the placement of the
-l flag is significant. If string x is of the form x.o, then
that file is searched for in the same places, but without
prepending `lib' or appending `.a' or `.dylib' to the filename.
So, either gcc silently passes -dynamic to ld, or it's an ld bug.
Luckily, I found this ld flag:
By default when the -dynamic flag is in effect, the -lx and
-weak-lx options first search for a file of the form
`libx.dylib' in each directory in the library search path, then
a file of the form `libx.a' is searched for in the library
search paths. This option changes it so that in each path
`libx.dylib' is searched for then `libx.a' before the next path
in the library search path is searched.
So, I tried to configure with:
% ./configure --with-normal --without-debug
Well, it builds! :-D
I don't know how to do, but it would be nice make configure able to
detect Mac OS X and automatically add "-Wl,-search_paths_first" to the
Andrea "XFox" Govoni
ICQ UIN: 43488185
Yahoo! ID: xfox82
Skype Name: draykan
Fingerprint: FBE1 CA7D 34BE 4A53 9639 5C36 B7A0 605F 212E 69C1