Re: libtool under msys bug

[Sam Thursfield]

Hi Ralf.
I've not made a test case before so I hope this is all good. I
basically stripped down a glib compile to find out the problem and
this was the result. Take a look at run.sh to see what is happening.
I've included all of the build debris so that you can see the failure
in action as well - run gobject/glib-genmarshal.exe and you should get
an "unable to find glib-2.0.dll" error.

Of course it's easy to test for the preceeding colon in the path
because I think it's always present, but I hope this is a good enough
example of it causing build failure under mingw/msys.

If you do want to compile and run the example for yourself, I presume
you will just need mingw, msys and msys's libtool, but I only tested
on my setup which is a lot more complete.
Sam

On Fri, Aug 22, 2008 at 4:38 PM, Sam Thursfield <address@hidden> wrote:
> On Fri, Aug 22, 2008 at 7:10 AM, Ralf Wildenhues <address@hidden> wrote:
>> Hi Sam,
>>
>> thanks for getting back to us on this.
>>
>> * Sam Thursfield wrote on Fri, Aug 22, 2008 at 05:07:41AM CEST:
>>> On Thu, Aug 21, 2008 at 9:28 PM, Ralf Wildenhues <address@hidden> wrote:
>>> >
>>> > Done.  Still, we would like to have a description of how to reproduce
>>> > the bug, so we can add a testcase.
>>>
>>> Hi, sorry about the delay.
>>
>> No problem at all of course.
>>
>>> It's proving more difficult to reproduce
>>> the bug than I anticipated - it occurs as I described during the
>>> builds of glib and gtk+, but it's taking a while to work out exactly
>>> what's causing the problem, as simple libtool projects don't exhibit
>>> the same behaviour. Tomorrow I'll have a go at reducing a glib build
>>> down to a testcase, rather than trying to come up with one from
>>> nowhere.
>>
>> Here's what would probably help us, even if you don't have further time:
>> show us how to reproduce the issue: which glib, gtk+ tarball did you use
>> and what was your configure command line.  Often, bugs can be narrowed
>> down just by looking at a build log, so if you could post that (gzip
>> large output, please) or put it up somewhere, that'd be cool, too.
>> Of course a testcase ready to apply is even nicer.  ;-)
>>
>
> Going to see what I can do now. One thing I have realised though is
> the bug is almost certainly caused by MSYS not Windows - the Windows
> PATH is ; seperated, and msys must do some mangling of its internal
> path variable before it executes a program to make a windows-style
> PATH. This is a tough thing to do as under msys, paths are : seperated
> but can also contain a colon, as in c:/foo/bar. Presumably the initial
> colon throws off this code so far. I still believe the simplest fix is
> patching libtool though, and having an initial : is slightly untidy.
>
> Will get back to you on reproduction and/or a testcase soon.
> Sam
>