reduce update

[Mark Brethen]

On Jan 19, 2012, at 11:47 PM, Joshua Root wrote:

> On 2012-1-20 13:30 , Mark Brethen wrote:
>> :info:build MACOSX_DEPLOYMENT_TARGET=10.6 /Developer/usr/bin/clang -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce-with-csl/work/trunk/csl/cslbase  -Dfontsdir=reduce.fonts -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include   -DBINDIR=/opt/local/bin -DPKGDATADIR=/opt/local/share/reduce  -pipe -O2 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk  -I/opt/local/include/freetype2 -I/opt/local/include -fno-strict-aliasing -O2 -Wall   -MT dyndemo.o -MD -MP -MF .deps/dyndemo.Tpo -c -o dyndemo.o /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce-with-csl/work/trunk/csl/cslbase/dyndemo.c
>> :info:build mv -f .deps/dyndemo.Tpo .deps/dyndemo.Po
>> :info:build MACOSX_DEPLOYMENT_TARGET=10.6 /Developer/usr/bin/clang -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce-with-csl/work/trunk/csl/cslbase  -Dfontsdir=reduce.fonts -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include   -DBINDIR=/opt/local/bin -DPKGDATADIR=/opt/local/share/reduce  -fPIC -fno-strict-aliasing -O2  /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce-with-csl/work/trunk/csl/cslbase/dynmodule.c  -o   dynmodule.so
>> :info:build Undefined symbols for architecture x86_64:
>> :info:build   "_main", referenced from:
>> :info:build       start in crt1.10.6.o
>> :info:build   "_variable_in_base", referenced from:
>> :info:build       _callme in cc-msGlG0.o
>> :info:build   "_function_in_base", referenced from:
>> :info:build       _callme in cc-msGlG0.o
>> :info:build ld: symbol(s) not found for architecture x86_64
>> Am I missing a flag that should be included in the portfile or is this an incompatibility with clang?
> 
> The linker defaults to creating an executable, which needs to have a
> main(). From its name I would assume that dynmodule.so is not meant to
> be an executable. If it's meant to be a dynamically loaded plugin-type
> object, use -bundle. If it's meant to be a library, use -dylib. The
> former would also explain the other undefined symbols, which you can
> tell the linker to find at runtime (assuming they will be defined by the
> program that loads the bundle) by using '-undefined dynamic_lookup'.
> 
> - Josh

I've opened Ticket #32973 to reflect developer changes to "play nice" with the MacPorts env. Could someone test this on snow leopard?

Thanks,

Mark