[GEM-dev] more mingwoes32

[Hans-Christoph Steiner]

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.