So with all the hassle over symlinks, there is a different issue stopping things on MinGW. This seems to be the exact same issue as Gem was having. You can see the environment of the build in the build log, if that's useful.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/home/pd/auto-build/pd-extended/pd/src -g -O2 -mms-bitfields -MT 0x260x260x7e.lo -MD -MP -MF .deps/0x260x260x7e.Tpo -c 0x260x260x7e.c -o 0x260x260x7e.o >/dev/null 2>&1 mv -f .deps/0x260x260x7e.Tpo .deps/0x260x260x7e.Plo /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -mms-bitfields -module -avoid-version -shared -shrext .dll -L/home/pd/auto-build/pd-extended/pd -L/home/pd/auto-build/pd-extended/pd/src -o 0x260x260x7e.la -rpath 0x260x260x7e.lo -lregex -lpd -lm -lgdi32 -luser32 -lkernel32 -lcoldname -lcrtdll libtool: link: only absolute run-paths are allowed
http://autobuild.puredata.info/auto-build/2011-09-30/logs/2011-09-30_03.31.0...
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 05:20 PM, Hans-Christoph Steiner wrote:
So with all the hassle over symlinks, there is a different issue stopping things on MinGW. This seems to be the exact same issue as Gem was having. You can see the environment of the build in the build log, if that's useful.
would it be possible to get the "svnversion" in the logs?
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 05:20 PM, Hans-Christoph Steiner wrote:
So with all the hassle over symlinks, there is a different issue stopping things on MinGW.
and how does this relate (e.g. timewise) to your other mail saying "Zexy installing .a instead of .dll on MinGW"?
this gave me the impression that at least one compilation succeeded (though it produced a static binary rather than a shared library)
fgmar IOhannes
On Fri, 2011-09-30 at 17:35 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 05:20 PM, Hans-Christoph Steiner wrote:
So with all the hassle over symlinks, there is a different issue stopping things on MinGW.
and how does this relate (e.g. timewise) to your other mail saying "Zexy installing .a instead of .dll on MinGW"?
this gave me the impression that at least one compilation succeeded (though it produced a static binary rather than a shared library)
pddev@windowsxp-i386:~$ svn --version svn, version 1.6.1 (r37116) compiled Apr 11 2009, 12:07:06
Its the same issue as with Gem. So running it from the command line alone without setting any variables, it builds. But running in the whole build, where lots of variables like DESTDIR, prefix, etc. are set, it doesn't work.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 06:08 PM, Hans-Christoph Steiner wrote:
pddev@windowsxp-i386:~$ svn --version svn, version 1.6.1 (r37116) compiled Apr 11 2009, 12:07:06
thanks. however, i actually was trying to ask for the svn-revision of externals/ (which you get by running "svnversion" within this directory), in order to be able to check which commits are already in action when the build is running.
Its the same issue as with Gem. So running it from the command line alone without setting any variables, it builds.
another reason to fix it "properly".
But running in the whole build, where lots of variables like DESTDIR, prefix, etc. are set, it doesn't work.
does "running from the command line" mean: $ cd externals && make zexy or does it mean $ cd externals/zexy && ./autogen.sh && .configure && make
e.g. is the problematic environment within externals/Makefile or within the entire build system?
if the latter, do you have any recommendations how to start such a build (preferably with only the zexy part, so we don't have to wait for ages) in a debugging session?
fgmasdr IOhannes
On Fri, 2011-09-30 at 18:17 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 06:08 PM, Hans-Christoph Steiner wrote:
pddev@windowsxp-i386:~$ svn --version svn, version 1.6.1 (r37116) compiled Apr 11 2009, 12:07:06
thanks. however, i actually was trying to ask for the svn-revision of externals/ (which you get by running "svnversion" within this directory), in order to be able to check which commits are already in action when the build is running.
Its the same issue as with Gem. So running it from the command line alone without setting any variables, it builds.
another reason to fix it "properly".
The error is caued by the -rpath option having no argument, i.e.
-rpath 0x260x260x7e.lo
Rather than
-rpath /extra/zexy 0x260x260x7e.lo
Too bad ./configure --disable-rpath doesn't seem to work with Gem or zexy's build setup. I thought that libtool/autoconf was supposed to set that up for you.
But running in the whole build, where lots of variables like DESTDIR, prefix, etc. are set, it doesn't work.
does "running from the command line" mean: $ cd externals && make zexy or does it mean $ cd externals/zexy && ./autogen.sh && .configure && make
e.g. is the problematic environment within externals/Makefile or within the entire build system?
if the latter, do you have any recommendations how to start such a build (preferably with only the zexy part, so we don't have to wait for ages) in a debugging session?
I just ran this and it worked (but are still producing .a rather than .dll):
cd externals/ make DESTDIR=/tmp zexy_clean zexy_install
Trying this now:
cd packages/win32_inno make install
.hc
On Fri, 2011-09-30 at 18:17 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 06:08 PM, Hans-Christoph Steiner wrote:
pddev@windowsxp-i386:~$ svn --version svn, version 1.6.1 (r37116) compiled Apr 11 2009, 12:07:06
thanks. however, i actually was trying to ask for the svn-revision of externals/ (which you get by running "svnversion" within this directory), in order to be able to check which commits are already in action when the build is running.
Its the same issue as with Gem. So running it from the command line alone without setting any variables, it builds.
another reason to fix it "properly".
But running in the whole build, where lots of variables like DESTDIR, prefix, etc. are set, it doesn't work.
does "running from the command line" mean: $ cd externals && make zexy or does it mean $ cd externals/zexy && ./autogen.sh && .configure && make
e.g. is the problematic environment within externals/Makefile or within the entire build system?
if the latter, do you have any recommendations how to start such a build (preferably with only the zexy part, so we don't have to wait for ages) in a debugging session?
I found the source of the problem, or at least one step further. $libpddir is set to $prefix. $prefix is empty on Windows and Mac OS X. Somehow, libtool wants to do "-rpath $libpddir", so it ends up as "-rpath ". Windows DLLs don't need the rpath since they are relocatable.
Still looking for how to solve this tho...
.hc
On Fri, 2011-09-30 at 18:17 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 06:08 PM, Hans-Christoph Steiner wrote:
pddev@windowsxp-i386:~$ svn --version svn, version 1.6.1 (r37116) compiled Apr 11 2009, 12:07:06
thanks. however, i actually was trying to ask for the svn-revision of externals/ (which you get by running "svnversion" within this directory), in order to be able to check which commits are already in action when the build is running.
Its the same issue as with Gem. So running it from the command line alone without setting any variables, it builds.
another reason to fix it "properly".
But running in the whole build, where lots of variables like DESTDIR, prefix, etc. are set, it doesn't work.
does "running from the command line" mean: $ cd externals && make zexy or does it mean $ cd externals/zexy && ./autogen.sh && .configure && make
e.g. is the problematic environment within externals/Makefile or within the entire build system?
if the latter, do you have any recommendations how to start such a build (preferably with only the zexy part, so we don't have to wait for ages) in a debugging session?
I tried --disable-rpath, but it said it wasn't a ./configure option. Its a recommended thing for MinGW:
http://www.mingw.org/wiki/RelocatableHOWTOforMinGW
I'm trying setting libpddir=/. for Windows, hopefully that doesn't break anything.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 08:23 PM, Hans-Christoph Steiner wrote:
I tried --disable-rpath, but it said it wasn't a ./configure option. Its a recommended thing for MinGW:
the "--disable-rpath" flag comes from the macro AC_LIB_RPATH (currently not used in zexy, hence it doesn't work....)
AC_LIB_RPATH seems to be shipped with gettext, and iirc there have beensome issues with gettext on some systems (of the PdLab??)
if you think it is ok to havve this additional dependency, i might just add the macro.
gmasdr IOhannes
On Sat, 2011-10-01 at 18:40 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 08:23 PM, Hans-Christoph Steiner wrote:
I tried --disable-rpath, but it said it wasn't a ./configure option. Its a recommended thing for MinGW:
the "--disable-rpath" flag comes from the macro AC_LIB_RPATH (currently not used in zexy, hence it doesn't work....)
AC_LIB_RPATH seems to be shipped with gettext, and iirc there have beensome issues with gettext on some systems (of the PdLab??)
if you think it is ok to havve this additional dependency, i might just add the macro.
It turns out that Mac OS X doesn't come with gettext, so it has to come from Fink, MacPorts, etc. gettext is in mingw-get now, so its easy to install on MinGW. And of course trivial on GNU/Linux.
.hc