-----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)
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/...
.hc
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-30 21:27, Hans-Christoph Steiner wrote:
Looks like we might want to try setting this in aclocal.m4 or something like that: hardcode_into_libs=no
do you have any more information on your suggestion? i never heard about it before.
aclocal.m4 is generated by autoconf, so we better not touch it (and instead but it into some other .m4 file)
doing a short inspection of the aclocal.m4 (generated on my debian box), it seems that "hardcode_into_libs" is set to "no" anyhow, for all but AIX, FreeBSD(>>2), GNU/Hurd, Haiku, HPUX (64bit), Interix, IRIX, Linux, NetBSD, QNX, Solaris, Sco and TPF.
fgamsdr IOhannes
On Aug 1, 2011, at 3:51 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-30 21:27, Hans-Christoph Steiner wrote:
Looks like we might want to try setting this in aclocal.m4 or something like that: hardcode_into_libs=no
do you have any more information on your suggestion? i never heard about it before.
aclocal.m4 is generated by autoconf, so we better not touch it (and instead but it into some other .m4 file)
doing a short inspection of the aclocal.m4 (generated on my debian box), it seems that "hardcode_into_libs" is set to "no" anyhow, for all but AIX, FreeBSD(>>2), GNU/Hurd, Haiku, HPUX (64bit), Interix, IRIX, Linux, NetBSD, QNX, Solaris, Sco and TPF.
Oh well, sounds like its there already. I was just searching the libtool docs for 'run-paths'. Does the build system think its making something other that .DLLs? As far as I know, Windows DLLs don't have any sense of their path, you can load them from anywhere. This is in contrast to .a or Mac OS X .dylibs files.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-01 17:00, Hans-Christoph Steiner wrote:
Oh well, sounds like its there already. I was just searching the libtool docs for 'run-paths'. Does the build system think its making something other that .DLLs? As far as I know, Windows DLLs don't have any sense of their path, you can load them from anywhere. This is in contrast to .a or Mac OS X .dylibs files.
so: building on w32 is (like always) a bit more complicated than in the rest of the world. afaics, there are several problems we are facing right now:
- - the autobuild currently fails with "libtool: link: only absolute run-paths are allowed"; according to a bit of googling, it seems like this is indeed a problem with "prefix" not being an absolute path. would it do any harm, to set PREFIX to a(n absolute) value, rather than set it to ""?
- - my builds currently don't produce .dll's, mainly because of unresolved symbols; either we have to add "-no-undefined" to the LDFLAGS on w32, or we need some more explicit linking (against pd.lib), to resolve all those symbols. i'm just waiting for the build to finish, to see whether the former (and simpler solution) is sufficient.
- - with my builds (in msys), i currently have to exclude scopeXYZ~.cpp, as the tilde in the filename confuses libtool, producing illegal commands and thus fails the build process. otoh, it seems like this works fine in the autobuilds, so it might be simply a problem of msys itself.
fgamsdr IOhannes
On Aug 2, 2011, at 5:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-01 17:00, Hans-Christoph Steiner wrote:
Oh well, sounds like its there already. I was just searching the libtool docs for 'run-paths'. Does the build system think its making something other that .DLLs? As far as I know, Windows DLLs don't have any sense of their path, you can load them from anywhere. This is in contrast to .a or Mac OS X .dylibs files.
so: building on w32 is (like always) a bit more complicated than in the rest of the world. afaics, there are several problems we are facing right now:
- the autobuild currently fails with "libtool: link: only absolute
run-paths are allowed"; according to a bit of googling, it seems like this is indeed a problem with "prefix" not being an absolute path. would it do any harm, to set PREFIX to a(n absolute) value, rather than set it to ""?
Yes, it wouldn't put the files in the right place. These settings are used on Mac OS X and it works. One thing that might make sense is to not set prefix in ./configure but only when running make.
- my builds currently don't produce .dll's, mainly because of
unresolved symbols; either we have to add "-no-undefined" to the LDFLAGS on w32, or we need some more explicit linking (against pd.lib), to resolve all those symbols. i'm just waiting for the build to finish, to see whether the former (and simpler solution) is sufficient.
--no-undefined seems fine for now, but my guess is that it'll bite in the long run.
- with my builds (in msys), i currently have to exclude
scopeXYZ~.cpp, as the tilde in the filename confuses libtool, producing illegal commands and thus fails the build process. otoh, it seems like this works fine in the autobuilds, so it might be simply a problem of msys itself.
That's an odd one. The auto-builds are run in the msys sh, see scripts/auto-build/run-automated-build.bat:
C:\msys\1.0\bin\sh.exe --login -i -c /home/pd/auto-build/pd-extended/ scripts/auto-build/run-automated-builder
.hc
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk43vsAACgkQkX2Xpv6ydvTfBQCfVBQPg8O4YV0ynxkovOQz96UQ TcAAn3jlyiCFILhVEvAUCE5xHwuI4D6X =QwVz -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-02 18:18, Hans-Christoph Steiner wrote:
- the autobuild currently fails with "libtool: link: only absolute
run-paths are allowed"; according to a bit of googling, it seems like this is indeed a problem with "prefix" not being an absolute path. would it do any harm, to set PREFIX to a(n absolute) value, rather than set it to ""?
Yes, it wouldn't put the files in the right place. These settings are used on Mac OS X and it works.
well afaict, it doesn't work on w32 right now, and you are calling configure with special arguments for w32 anyhow, so i don't get the argument about OSX. linking works fundamentally different on OSX than on w32.
One thing that might make sense is to
not set prefix in ./configure but only when running make.
the problem is, that configure is doing fine, but make is failing :-(
however, i still don't fully understand what you are trying to fix with an empty PREFIX. where is that empty PREFIX located? do you assume that it is in the current directory? is it meant to just be a void target, where files will vanish unnoticed? i'm just afraid that you are triggering undefined behaviour using an empty PREFIX.
if the problem is install targets, you might want to set the - --includedir (despite common believe, this is not where configure will look for headers but where it will install headers to) and the --libdir flags in configure, in order to get the installation paths right.
if this doesn't work (e.g.: the linker still fails), you could still override the installation paths during "make install" time (i don't see a necessity to do it during "make all" time), by setting "libdir", "pkglibdir" and/or "includedir".
in any case i would either leave prefix alone, or set it to something meaningfull, e.g. "/".
fgasdmr IOhannes
On Aug 3, 2011, at 3:48 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-02 18:18, Hans-Christoph Steiner wrote:
- the autobuild currently fails with "libtool: link: only absolute
run-paths are allowed"; according to a bit of googling, it seems like this is indeed a problem with "prefix" not being an absolute path. would it do any harm, to set PREFIX to a(n absolute) value, rather than set it to ""?
Yes, it wouldn't put the files in the right place. These settings are used on Mac OS X and it works.
well afaict, it doesn't work on w32 right now, and you are calling configure with special arguments for w32 anyhow, so i don't get the argument about OSX. linking works fundamentally different on OSX than on w32.
One thing that might make sense is to
not set prefix in ./configure but only when running make.
the problem is, that configure is doing fine, but make is failing :-(
however, i still don't fully understand what you are trying to fix with an empty PREFIX. where is that empty PREFIX located? do you assume that it is in the current directory? is it meant to just be a void target, where files will vanish unnoticed? i'm just afraid that you are triggering undefined behaviour using an empty PREFIX.
if the problem is install targets, you might want to set the
- --includedir (despite common believe, this is not where configure
will look for headers but where it will install headers to) and the -- libdir flags in configure, in order to get the installation paths right.
if this doesn't work (e.g.: the linker still fails), you could still override the installation paths during "make install" time (i don't see a necessity to do it during "make all" time), by setting "libdir", "pkglibdir" and/or "includedir".
in any case i would either leave prefix alone, or set it to something meaningfull, e.g. "/".
I don't really care what combo of DESTDIR, prefix, libdir, pkglibdir, etc. is used as long as things get installed correctly. The current combo, with prefix=, has been working on Mac OS X for a while on other build systems as well. Like for Pd itself, for example.
The files need to end up in /c/home/pd/auto-build/pd-extended/packages/ win32_inno/build/ . The installer will then take everything in that directory and install it into %ProgramFiles%\pd. So DESTDIR is /c/ home/pd/auto-build/pd-extended/packages/win32_inno/build, then in order to get everything in DESTDIR to end up installed in %ProgramFiles %\pd, prefix has to be blank. Then
/c/home/pd/auto-build/pd-extended/packages/win32_inno/build/bin
will be installed as
%ProgramFiles%\pd\bin
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2011 08:38 PM, Hans-Christoph Steiner wrote:
The files need to end up in /c/home/pd/auto-build/pd-extended/packages/win32_inno/build/ . The installer will then take everything in that directory and install it into %ProgramFiles%\pd. So DESTDIR is /c/home/pd/auto-build/pd-extended/packages/win32_inno/build, then in order to get everything in DESTDIR to end up installed in %ProgramFiles%\pd, prefix has to be blank. Then
hmm, if the prefix is "/", it would end up there as well, or do i miss something?
fgmadr IOhannes
On Aug 3, 2011, at 3:14 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2011 08:38 PM, Hans-Christoph Steiner wrote:
The files need to end up in /c/home/pd/auto-build/pd-extended/packages/win32_inno/build/ . The installer will then take everything in that directory and install it into %ProgramFiles%\pd. So DESTDIR is /c/home/pd/auto-build/pd-extended/packages/win32_inno/build, then in order to get everything in DESTDIR to end up installed in %ProgramFiles%\pd, prefix has to be blank. Then
hmm, if the prefix is "/", it would end up there as well, or do i miss something?
Sounds like its worth a try. I just committed it, so we'll see. It now gets to the scopeXYZ error that you mentioned before.
.hc
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
On Aug 3, 2011, at 3:14 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2011 08:38 PM, Hans-Christoph Steiner wrote:
The files need to end up in /c/home/pd/auto-build/pd-extended/packages/win32_inno/build/ . The installer will then take everything in that directory and install it into %ProgramFiles%\pd. So DESTDIR is /c/home/pd/auto-build/pd-extended/packages/win32_inno/build, then in order to get everything in DESTDIR to end up installed in %ProgramFiles%\pd, prefix has to be blank. Then
hmm, if the prefix is "/", it would end up there as well, or do i miss something?
No such luck, it still fails with --prefix=/ The weird thing is that it seems to work when manually run in the msys shell on the build server. Perhaps its somehow related to env vars? Here's the diff between running 'set' in the msys shell and in the auto-build script:
$ diff -uw shell.log script.log --- shell.log 2011-08-05 13:16:26.715625600 -0400 +++ script.log 2011-08-05 13:16:48.957608000 -0400 @@ -4,20 +4,21 @@ BASH=/bin/sh BASH_ARGC=() BASH_ARGV=() -BASH_LINENO=() -BASH_SOURCE=() +BASH_LINENO=([0]="0") +BASH_SOURCE=([0]="./pd-extended-auto-builder.sh")
BASH_VERSINFO=([0]="3" [1]="1" [2]="0" [3]="1" [4]="release" [5]="i686- pc-msys") BASH_VERSION='3.1.0(1)-release' BGCOLOR=LightYellow +BUILD_DIR=win32_inno CLASSPATH='.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip' CLIENTNAME='My Computer' COLORFGBG='default;default' COLORTERM=rxvt-xpm -COLUMNS=80 COMMONPROGRAMFILES='C:\Program Files\Common Files' COMPUTERNAME=WINDOWSXP-I386 COMSPEC='C:\WINDOWS\system32\cmd.exe' CVS_RSH=ssh +DATE=2011-08-05 DIRSTACK=() DISPLAY=:0 EUID=500 @@ -25,20 +26,17 @@ FP_NO_HOST_CHECK=NO GROUPS=() HISTFILE=/home/pd/.bash_history -HISTFILESIZE=500 -HISTSIZE=500 HOME=/home/pd HOMEDRIVE=C: HOMEPATH='' -HOSTNAME=WINDOWSXP-I386 +HOSTNAME=windowsxp-i386 HOSTTYPE=i686 IFS=' ' -LINES=26 LOGNAME=pd LOGONSERVER='\WINDOWSXP-I386' MACHTYPE=i686-pc-msys -MAILCHECK=60 +MAIL_COMMAND='email --smtp-server mail.iem.at' MAKE_MODE=unix MINGW32BGCOLOR=LightYellow MINGW32FGCOLOR=Navy @@ -47,7 +45,7 @@ MSYSFGCOLOR=Black MSYSTEM=MINGW32 NUMBER_OF_PROCESSORS=1 -OLDPWD=/home/pd +OLDPWD=/home/pd/auto-build/pd-extended OPTERR=1 OPTIND=1 OS=Windows_NT @@ -56,28 +54,29 @@ PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PIPESTATUS=([0]="0") POSIXLY_CORRECT=y -PPID=5656 +PPID=1772 PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER='x86 Family 6 Model 8 Stepping 10, GenuineIntel' PROCESSOR_LEVEL=6 PROCESSOR_REVISION=080a PROGRAMFILES='C:\Program Files' PROMPT='$P$G' -PS1='[\033]0;$MSYSTEM:\w\007 -\033[32m]\u@\h [\033[33m\w\033[0m] -$ ' -PS2='> ' PS4='+ ' -PWD=/home/pd/auto-build/pd-extended/scripts/auto-build +PWD=/home/pd/auto-build/pd-extended/packages/win32_inno QTJAVA='C:\Program Files\Java\jre6\lib\ext\QTJava.zip' +RECIPIENT=pd-cvs@iem.at +SCRIPT=pd-extended-auto-builder.sh +SCRIPT_DIR=. SESSIONNAME=RDP-Tcp#5 SHELL=/bin/sh -SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive- comments:monitor:posix -SHLVL=1 +SHELLOPTS=braceexpand:hashall:interactive-comments:posix +SHLVL=2 +SYSTEM=mingw32_nt-5.1 SYSTEMDRIVE=C: SYSTEMROOT='C:\WINDOWS' TEMP=/tmp TERM=msys +TIME=13.15.14 TMP=/tmp UID=500 USERDOMAIN=WINDOWSXP-I386 @@ -85,5 +84,5 @@ USERPROFILE='C:\Documents and Settings\pd' WINDIR='C:\WINDOWS' WINDOWID=167838880 -_=ls -i='/etc/profile.d/*.sh' +_='--- environment ----------------------------------------' +auto_build_root_dir=/home/pd/auto-build/pd-extended
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Aug 5, 2011, at 1:31 PM, Hans-Christoph Steiner wrote:
On Aug 3, 2011, at 3:14 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2011 08:38 PM, Hans-Christoph Steiner wrote:
The files need to end up in /c/home/pd/auto-build/pd-extended/packages/win32_inno/build/ . The installer will then take everything in that directory and install it into %ProgramFiles%\pd. So DESTDIR is /c/home/pd/auto-build/pd-extended/packages/win32_inno/build, then in order to get everything in DESTDIR to end up installed in %ProgramFiles%\pd, prefix has to be blank. Then
hmm, if the prefix is "/", it would end up there as well, or do i miss something?
No such luck, it still fails with --prefix=/ The weird thing is that it seems to work when manually run in the msys shell on the build server. Perhaps its somehow related to env vars? Here's the diff between running 'set' in the msys shell and in the auto-build script:
[snip]
So I think I found the answer, it has to do with -rpath. When run in the autobuild, the command that has the weird libtool run-paths error has this snippet in it:
-o Gem.la -rpath -L/home/pd/auto-build/pd-extended/pd
When I run the make from the msys run directly, this same snippet looks like:
-o Gem.la -rpath /extra/Gem -L/home/pd/auto-build/pd-extended/pd
On MinGW, we don't need rpath since DLLs are relocatable, they don't have a hardcoded path in them. So I'm adding --disable-rpath and trying the build again. Wish me luck!
Otherwise, the scopeXYZ thing is still a problem...
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-17 00:25, Hans-Christoph Steiner wrote:
On MinGW, we don't need rpath since DLLs are relocatable, they don't have a hardcoded path in them. So I'm adding --disable-rpath and trying the build again. Wish me luck!
Ay Ahurai Bozorg Man Niazmand va bande to am mara Amorzesh Kon Va Shans Va Movafaghiat ra dar Man Ashkar Saz Va mara be rahe Rast Hedaiat Kon
On Aug 17, 2011, at 2:50 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-17 00:25, Hans-Christoph Steiner wrote:
On MinGW, we don't need rpath since DLLs are relocatable, they don't have a hardcoded path in them. So I'm adding --disable-rpath and trying the build again. Wish me luck!
Ay Ahurai Bozorg Man Niazmand va bande to am mara Amorzesh Kon Va Shans Va Movafaghiat ra dar Man Ashkar Saz Va mara be rahe Rast Hedaiat Kon
No luck, I guess this was a curse rather than a blessing ;) The - rpath is still there and still empty. Arg... any ideas?
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-02 18:18, Hans-Christoph Steiner wrote:
- my builds currently don't produce .dll's, mainly because of
unresolved symbols; either we have to add "-no-undefined" to the LDFLAGS on w32, or we need some more explicit linking (against pd.lib), to resolve all those symbols. i'm just waiting for the build to finish, to see whether the former (and simpler solution) is sufficient.
--no-undefined seems fine for now, but my guess is that it'll bite in the long run.
i think it's "-no-undefined" (single dash at the beginning), which is a flag to libtool.
anyhow, when trying that i now do get a lot of errors, that the linker cannot resolve Pd's symbols (unfortunately i get an error for each unresolved symbol on each of the 540 or so object files, so i cannot properly tell which symbols apart from pd.lib are missing)
the linking stage takes quite long, so i'll have to resort to a dummy library first ...
fgmasdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig