This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport patch: suppress libtool fixup step

On Wed, 2010-07-07 at 15:21 -0400, Charles Wilson wrote:
> Really?  Other than the packaging issues, I had no problem with JonY's 
> src snapshot, compiling a 64bit-default, but multilib enabled, gcc.  did 
> something break upstream between when JonY took his snapshot and today, 
> or are you referring to some other problem?

I meant with cygport: strip(1)ing, cygconf handling of
--build/host/target, definition of $CC and friends, dependency listings,
and more.  There are a lot of cygwin-cygwin-cygwin assumptions in the
code that need to be revised, but I'm making progress.

As for the packaging, I don't agree with the current packaging, but I'll
save my opinion for my response to his ITP.

> It is...tricky, no doubt.  But all problems have solutions...depending 
> on how much effort and/or how much in-elegance you're willing to put up 
> with. <g>
> And, of course, whether the benefits outweigh those costs. Since JonY's 
> doing the work, I'm willing to defer to his judgment on that once all 
> the costs are documented on the list and he can make an informed decision.

OOTB gcc multilib does not build, nor AFAICS do clear-cut patches exist
to fix it.  Others in #mingw-w64 seem to think that multilib isn't worth
the headache, at least not yet.  We'll see what I come up with over the
next few days, but right now I'm going with a non-multilib gcc as my
working example.

> Am I correct in supposing you'd favor two mingw64 compilers:
>     64bit default, multilib (because "multilib makes sense for a 64bit 
> compiler") based on mingw64
> PLUS a
>     32bit *non-multilib* mingw64 compiler (because "[multilib] makes no 
> sense for a 32bit compiler", and "there is a place for both [mingw64 
> 32bit and 32bit, as I read your statement in context]")
> and a separate
>     32bit compiler ("there is a place for both")

Yes, I believe that there is place for all three of those.

> Well, to an extent I agree. But...what if you're building a 
> cross-compiled package (say, mingw-xz, with liblzma), and installing 
> into a sysroot (e.g. --prefix=/something/other/than/usr:
>     /usr/sysroot/mingw32/lib/
> In that case, wouldn't the corresponding DLL go into
>     /usr/sysroot/mingw32/bin/liblzma-0.dll
> That is, ../bin ?

That would be libtool's default, but that doesn't make it right.  My
changes to the libtool fixups would move it back into lib.

> Or, are you talking only and specifically about the DLLs associated with 
> the gcc runtime libraries, like libgcc_s-sjlj-1.dll?

Remember that libgcc is not a libtool library.  But the other gcc libs
are, and I would also leave them alongside their .la's.

> Wonderful, and I appreciate that very much. This (and the entire cluster 
> of related) discussion have a great potential to turn into bikeshedding 
> confabs, so contributions by folks who, like yourself, are actually 
> rolling up their sleeves and pitching in are MUCH appreciated.
> Thank you.

You're welcome.  I knew this was a deficiency in cygport for a long
time, but I needed someone to give me something concrete to work with.

> Ah, but before they can be fixed, you must determine what the correct 
> behavior should BE.  I don't think leaving dll's -- particularly for 
> cross-compilED packages (aka (1), above) -- in the same directory as the 
> .la is the right thing to do.  For the compiler's $target runtime 
> DLLs...I don't know. Certainly they do not belong in /usr/bin, whatever 
> happens.  Where they SHOULD go -- I don't think we've determined that yet.

My POV is that a cygwin-hosted mingw*-target compiler is no different
than any other cross-compiler: nothing on the system is meant to *run*
with the $target libraries, because in 99% of cross-compiles that's
impossible.  Therefore, they don't need to be in PATH (or in a place
which is conveniently added to PATH).

As you say, they obviously don't belong in /usr/bin (they're not needed
there, and the three mingw* would collide), nor in /usr/$target/bin (not
its purpose).  The only place that does make sense is alongside the .la,
just as it would be with with other cross-compilers.  You wouldn't move
a cross-compiler to /usr/lib or put its toolexeclibdir in
LD_LIBRARY_PATH, would you?

So right now my approach
is /usr/bin/$target-foo.exe, /usr/$target/{bin,include,lib}
and /usr/lib/gcc/$target/$version, with conflicting data (e.g. infos and
locales) removed, as the latter could be shared by the native

> However, if additional cygport changes are planned and ongoing to make 
> this cross stuff work better -- than I shall now do the Snoopy Dance of Joy.

I'm not limiting this to mingw32/64; my intent is to make a generic
solution that will work for *any* target.  I plan to test with a
i686-pc-linux-gnu toolchain as well, time permitting.

> I *DO* wish that somebody had chimed in to the discussion earlier, 
> before JonY and I had progressed very far along.  My original 
> suggestions -- most of them, anyway -- were intended to start 
> discussions, not necessarily be taken as immediate instructions for 
> JonY.  However, he did act on them almost immediately -- and nobody 
> complained. So, we kept going.
> Now we have a lot of track to retrace. I feel bad for JonY.  Maybe we @ 
> cygwin and cygwin-apps can get this all nailed down for him, before he 
> returns next week.

I intend on doing just that, with a response to his ITP containing a
beta cygport(1) and a complete set of revised .cygports to match.  Stay


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]