This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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 mingw.org 32bit, as I read your statement in context]")
>
> and a separate
>
> 32bit mingw.org 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/liblzma.la
> 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 libgcc_s.so.1 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
binutils/gcc.
> 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
tuned.
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple