Missing LDSHARED in Makefiles; build problems.

jason jac4 at andrew.cmu.edu
Thu Dec 25 08:37:09 CST 2003


> I don't know why this occurs or how to fix it. If I figure something out
> I'll post it here, but does anybody know what's up, or has anybody had any
> luck building Wine on OS X?

Well, this appears to have been resolved in the 20031212 release. However,
now I am having a different problem. Once again, make:

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__
-DBINDIR="\"/usr/bin\"" -DDLLDIR="\"/usr/lib/wine\"" -D_REENTRANT -fPIC
-Wall -fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2 -ffixed-r13
-no-cpp-precomp -D__powerpc__ -o port.o port.c
gcc -dynamiclib config.o debug.o ldt.o loader.o port.o  -L../../libs/port
-lwine_port    -lpoll -lm  -o libwine.1.dylib
ld: Undefined symbols:
_environ
/usr/bin/libtool: internal link edit command failed
make[2]: *** [libwine.1.dylib] Error 1
make[1]: *** [wine] Error 2
make: *** [libs] Error 2

It can't resolve _environ when -dynamiclib is specified. Apparently
environ doesn't link right on dylib's on Mac OS. Many sources on the
internet suggest using _NSGetEnviron() instead, as in:

#ifdef __APPLE__
#include <crt_externs.h>
char **environ = *_NSGetEnviron();
#else
extern char **environ;
#endif

This works just fine and all the libraries link. So, yet another problem.
The toplevel lib Makefile doesn't like the fact that the .dylib's are
built in the specific lib directories rather than in wine/libs. Creating
symbolic links to the libs by hand works just fine. From wine/libs, after
building the libs:

ln -s wine/libwine.dylib libwine.dylib
ln -s unicode/libwine_unicode.dylib libwine_unicode.dylib

It is only those two that need links. port, uuid, and wpp are all linked
to correctly from libs already, for some reason.

Next problem (sigh): The symbols _getopt, _opterr, _optind, and _optopt
are multiply defined in both libwine_port and libSystem. This problem was
encountered when linking tools/wrc. My solution was to manually #define
ELIDE_CODE in libs/port/getopt.c and libs/port/getopt1.c. This prevented
the "custom" getopt code from being compiled into the library and fixed
all the problems.

The above "fixes" allowed me to continue the build, which is apparently
working correctly now. I am currently waiting for it to finish and will
post anything else if it comes up. Sorry, but I don't understand enough
about how this stuff works to make an "official" patch. Hopefully somebody
else will take care of these issues.

Jason



More information about the wine-users mailing list