[GEM-dev] more mingwoes32

Hans-Christoph Steiner hans at at.or.at
Sat Jul 30 21:27:28 CEST 2011


On Jul 29, 2011, at 6:37 PM, Hans-Christoph Steiner wrote:

>
> On Jul 28, 2011, at 10:28 PM, IOhannes m zmölnig wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> the mingw32 autobuilds still fail (too early [*])
>>
>>
>> <log>
>> make[6]: Leaving directory
>> `/home/pd/auto-build/pd-extended/externals/Gem/src/deprecated'
>> make[6]: Entering directory
>> `/home/pd/auto-build/pd-extended/externals/Gem/src'
>> /bin/sh ../libtool --tag=CXX --preserve-dup-deps  --mode=link g++ - 
>> DPD
>> - -I/home/pd/auto-build/pd-extended/pd/src  -DHAVE_S_STUFF_H -O2
>> - -mcpu=i586 -mtune=pentium3 -freg-struct-return -O3 -falign-loops
>> - -falign-functions -falign-jumps -funroll-loops -ffast-math -msse2
>> - -module -avoid-version -shared -shrext .pd_mingw32   -o Gem.la - 
>> rpath
>> - -L/home/pd/auto-build/pd-extended/pd -lopengl32  -lm -lglu32 - 
>> lopengl32
>> -lm Gem/libGem.la RTE/libRTE.la Utils/libUtils.la Base/libBase.la
>> plugins/libplugins.la Controls/libControls.la Geos/libGeos.la
>> Manips/libManips.la Nongeos/libNongeos.la openGL/libopenGL.la
>> Particles/libParticles.la Pixes/libPixes.la  -ldl -lz -lm
>> - -L/home/pd/auto-build/pd-extended/pd
>> libtool: link: only absolute run-paths are allowed
>> make[6]: *** [Gem.la] Error 1
>> </log>
>>
>> now that's a weird error.
>> after some frustratingg googling, i also noticed:
>>
>> <log>
>> ./configure \
>> 	CXXFLAGS="-DHAVE_S_STUFF_H -O2 -mcpu=i586 -mtune=pentium3" \
>> 		--prefix= \
>> 		--libdir=/extra \
>> 		--disable-mmx \
>> 		--enable-sse2 \
>> 		--without-quicktime \
>> 		--with-video=plugins \
>> 		--with-film=plugins \
>> 		--with-pd=/home/pd/auto-build/pd-extended/pd
>> </log>
>>
>> the weird part here is
>> <log>
>> - --prefix= --libdir=/extra
>> </log>
>>
>> what is the exact reasoning behind this? i guess that the idea is  
>> to set
>> DESTDIR to /path/to/PD/, but i do believe that this is confusing
>> automake/libtool.
>>
>> probably a better idea (though not tested at all) would be do add a
>> "libdir=/foo/bar" (or "pkgdir=/foo/bar") stanza to the "make install"
>> invocation rather than trying to do this via configure flags.
>>
>> mfgasdr
>> IOhanens
>>
>>
>> [*] i have to admit, that even in my testbuilds, the w32 autobuilds
>> would not suceed; however, the problem is a different one (and i  
>> believe
>> it's triggered after the one discussed here)
>
>
>
> --libdir=/extra is to support the flat dir layout used on Windows  
> and Mac OS X.  It works on Mac OS X, so I can't see how it wouldn't  
> work on Windows.  Plus /extra is ab absolute path, so that should be  
> fine.  That error stumped me too.  My guess right now is perhaps it  
> has something to do with Windows paths, probably in DESTDIR.   
> Perhaps libtool is confused because the DESTDIR path doesn't start  
> with /c/home/pd/... but is just /home/pd/...
>

Looks like we might want to try setting this in aclocal.m4 or  
something like that:
hardcode_into_libs=no

As far as I know, DLLs don't have hardcoded paths.  Another option  
would be to try to prepend $SYSTEMDRIVE to the DESTDIR to make it a  
fully absolute path.

.hc



----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.        - retired U.S. Army general, William Odom





More information about the GEM-dev mailing list