This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote:
> Hmm. That's what I *was* doing: JonY's -src provides a cygport that
> appears to work. You have to impose some workarounds, like:
>
> RESTRICT=strip
>
> and manually use the target strip tool within src_install, but...it
> *works*. (E.g. how much 'in-elegance' do you want to put up with).
I didn't mean the .cygport(5), I meant cygport(1). The goal is to make
these workarounds unnecessary.
> Honestly, I just don't get this. Are you participating in a live
> #mingw-w64 session, or looking at old logs?
Live; I've been there since yesterday.
> The mingw64-gcc I *just built* /is/ multilib, and I generated all the
> necessary packages including two versions of all the language runtimes.
> Using cygport (with the two tiny patches you don't like, but that's not
> a reflection on *gcc*'s multilib support).
>
> So, it *does* build. Whether the packages so generated, once actually
> installed by setup.exe, WORK properly, I haven't yet tested. But that's
> not what you were saying: that multilib didn't "work". You said it
> doesn't "build" -- but JonY and I both built it.
>
> Hence my confusion.
Then I'm missing something, because the packages I grabbed from
sourceforge didn't build multilib, and I was told that additional
patches were necessary.
> I agree (willing to be persuaded that all three compilers could be
> NON-multilib, but it seems JonY *wants* to provide multilib -- I guess
> for just the default-to-64bit compiler -- and I'm not gonna stand in his
> way, if he'd doing the work.
I don't mind if it's not multilib, it would certainly make things
easier.
> But the difference is, we are NOT actually talking about two completely
> separate platforms. You CAN run mingw apps and use mingw DLLs from
> "cygwin" directly (mingw64-32, or mingw.org), because it's running on
> top of plain old windows. Ditto mingw64-64 -- assuming you're on a
> 64bit Windows.
I still believe that within the context of Cygwin, that mingw* is no
different than any other cross-compiler. This is an important
distinction when we talk about runtime data (more on that below).
> And...libtool already makes allowances for this: that's why cygwin
> specifically uses the 'cyg' prefix for all DLLs, so they won't conflict
> with mingw libs that could be in use simultaneously on the same machine (*).
And I won't mention how many problems the 'cyg' prefix has *caused*.
> I would REALLY like to be able to set $PATH to include
> /usr/sysroot/mingw32/bin and test (for example) mingw-bzip2.exe WITHOUT
> having to go manually copy
> /usr/sysroot/mingw32/lib/libbz2_2.dll,
> /usr/lib/gcc/i686-pc-mingw32/4.6.0/libgcc_s-1.dll
> to /usr/sysroot/mingw32/bin/ before I can! (And then, have to remember
> to redo that every time something gets updated in its "proper" buried
> location).
The (sole?) purpose of /usr/$target/bin is to contain binutils'
cross-tools. As Cygwin native EXEs they depend on the libraries
in /usr, not those under /usr/$target. Therefore is it unnecessary to
put the /usr/$target/lib DLLs in /usr/$target/bin, because the EXEs
there don't need them. Not only that, if you're not careful with PATH,
then /usr/$target/bin/foo.exe will come before /usr/bin/foo.exe, and
that's not good.
> Again, ONLY if you shackle Dave Korn and JonY together at the hip, and
> require that all compiler versions, for any $target, remain in lockstep
> forever. I don't think that is fair to either maintainer. (Or to John
> Doe, if he steps forward to provide a $target=linux cross compiler).
I suspect that a matching $major.$minor would be enough for NLS to work;
that's why we wanted to know which version Dave would package next. I
would think that we're getting to the point that we can keep the Cygwin
GCC up to date.
> If /opt is completely unacceptable, then I'd prefer allowing the cross
> toolchains to use $target-specific --datarootdirs.
>
> /usr/bin/$target-foo.exe
> /usr/$target/{bin,include,lib}
> /usr/$target/share/{info,man,locale} <<<--- datarootdir
> /usr/lib/gcc/$target/$version
Remember that (AFAIK) only binutils and gcc will have runtime data
(locales) because they are the only ones that are meant to be run; other
packages (mingw*-runtime, mingw*-pthreads, mingw*-zlib, etc.) need no
runtime data because they are not intended to be run within Cygwin.
The info and man7 pages are just documentation, not real runtime data,
and don't need duplicates. The man1 pages are $target-prefixed so they
don't collide. AFAICS the only real runtime data is the locales. I
don't think that justifies a separate $datarootdir; either we "borrow"
from cygwin-gcc4 (even if they're not a perfect match), or we can
disable NLS altogether.
> Although the *cygwin* specific docs would still go in
> /usr/share/doc/Cygwin/*
> and maybe
> /usr/share/doc/$pkg/
> but perhaps that last one also belongs over in the 'new' datarootdir.
No, because that won't collide with the cygwin-native version.
> what about this:
>
> mingw64-tc64-gcc.cygport:
> ...
> inherit cross
> inherit mingw-cross
> ...
>
> where mingw-cross.cygclass extends the generic cross support to do some
> of the *special* things that are appropriate to a mingw-$target cross
> compiler on cygwin-$host?
>
> like moving dll's to places other than where libtool wants to put them
> by default, AND different than where .so's would go on linux...
The libtool fixups are not handled by a cygclass, so there's no need for
two separate cygclasses.
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