libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: w32 ports of Libtool


From: Duft Markus
Subject: RE: w32 ports of Libtool
Date: Mon, 10 Mar 2008 08:50:16 +0100

Hi Ralf, Peter!

Peter Rosin <mailto:address@hidden> wrote:
> On Sun, Mar 09, 2008 at 02:53:20PM +0100, Ralf Wildenhues wrote:
>> Hello Peter, Markus,
>> 
>> in order to give some perspective for both of your w32 ports of
>> Libtool: when we make the switch to git as primary repo, we intend
>> to import your patch series in topic branches to allow for easier
>> work and integration of them into the master tree (and to hopefully
>> synchronize any issues of them with each other).

Cool, something moving :)

> 
> Ok, in preparation for this, I re-scanned the wgcc patch from last
> month and found no conflicts with my patch series. But that is hardly
> surprising since my patches only trigger stuff from inside mingw
> constructs (or is transparent) and the wgcc stuff is inside
> winnt*/__PARITY__ constructs. 

Yes, i think my patches should be pretty much encapsulated. The only
thing i can think of is the .exe handling stuff for cygwin/mingw, which
i killed for parity, but thats only a few lines.

> 
> If I would have added my testsuite tweaks there would certainly be
> clashes, but from a cursory look the changes to the testsuite from
> Markus is probably helping my patches more that not so I'll just work
> from there.

The testsuite should pretty much work on win32 with my patch. But you
may require some extra dllimport/dllexport stuff, which parity handles
(partially) transparently. But parity will definitely be able to use the
testsuite if it is usable on win32 without parity...

> 
> And the wgcc patch could perhaps(?) use the compile_tag variable from
> my patch series to add -xc++ for C++ compiles.

Parity detects the source type by extension automatically, but maybe
there are cases where this would help, yes.

Another thing: maybe it would be cool in some cases to use lib.exe for
parity too if it is found, and ar only as fallback. The reason is, that
the system ar from interix is sometimes failing to build libraries with
C++ objects inside (microsoft's name mangling maybe?). Newer ars seem to
work fine (but sometimes spit warnings), but i cannot put binutils as a
prerequisite for parity (also since some part of binutils must be
deativated, since they don't work).

Cheers, Markus

> 
> (Oh, and Ralf, please use my @lysator address...)
> 
> Cheers,
> Peter





reply via email to

[Prev in Thread] Current Thread [Next in Thread]