[GEM-dev] more mingwoes32

IOhannes m zmölnig zmoelnig at iem.at
Fri Jul 29 04:28:12 CEST 2011


-----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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4yGrwACgkQkX2Xpv6ydvTUdACcCYDtAfNYOEywX92BshIdCHmk
CUsAnjfr/jrU/MvUOo7tjk4H/WU2uV7K
=8315
-----END PGP SIGNATURE-----



More information about the GEM-dev mailing list