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.
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
