When you compile loadable libraries, you're not using the CPPFLAGS and LDFLAGS I requested at configure time.
For example:
% CC=cc CFLAGS="-Os -arch x86_64" CPPFLAGS=-isystem/opt/local/include LDFLAGS="-L/opt/local/lib -arch x86_64" ./configure --prefix=/opt/local
% make -j8
% cd extensions/curl
% make
Making all in lib/stklos
../../../../utils/tmpcomp -C -o curl-incl.c curl.stk
cc -Os -arch x86_64 -fPIC -fno-common \
-I../../../../src -I/opt/local/include \
-c -o curl.o curl.c
curl.c:177:11: warning: initializing 'char *' with an expression of type 'const char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
char *name = KEYWORD_PNAME(opt);
^ ~~~~~~~~~~~~~~~~~~
1 warning generated.
cc -bundle -flat_namespace -undefined suppress -o curl.so curl.o -lcurl
/bin/rm -f curl.o
Making all in demos
../../../utils/tmpcomp -o imap imap.stk
../../../utils/tmpcomp -o cat-url cat-url.stk
make[1]: Nothing to be done for `all-am'.
The CPPFLAGS I asked for (-isystem/opt/local/include) aren't there on the cc compile line. (-I/opt/local/include, which comes from GCINC, is there and is equivalent in this case, but imagine I were requesting something else in CPPFLAGS that wasn't already there).
The LDFLAGS I asked for (-L/opt/local/lib -arch x86_64) aren't there on the cc link line. As a result, the library is linked with the version of curl provided by the OS vendor in /usr/lib rather than the one in /opt/local/lib that I wanted to use:
% otool -L lib/stklos/curl.so
lib/stklos/curl.so:
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
And if the architecture I asked to build for weren't my compiler's default, the link would have failed. (The object was compiled for the arch I asked for because my CFLAGS were used, but then it tried to link it into a library of the compiler's default arch because my LDFLAGS weren't used.)
This problem affects not only the extensions in the extensions directory but also the loadable libraries that are part of the basic STklos install.
When you compile loadable libraries, you're not using the
CPPFLAGS
andLDFLAGS
I requested at configure time.For example:
The
CPPFLAGS
I asked for (-isystem/opt/local/include
) aren't there on thecc
compile line. (-I/opt/local/include
, which comes fromGCINC
, is there and is equivalent in this case, but imagine I were requesting something else inCPPFLAGS
that wasn't already there).The
LDFLAGS
I asked for (-L/opt/local/lib -arch x86_64
) aren't there on thecc
link line. As a result, the library is linked with the version of curl provided by the OS vendor in /usr/lib rather than the one in /opt/local/lib that I wanted to use:And if the architecture I asked to build for weren't my compiler's default, the link would have failed. (The object was compiled for the arch I asked for because my
CFLAGS
were used, but then it tried to link it into a library of the compiler's default arch because myLDFLAGS
weren't used.)This problem affects not only the extensions in the extensions directory but also the loadable libraries that are part of the basic STklos install.