X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-50.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_YG X-Spam-Check-By: sourceware.org Subject: Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step] From: "Yaakov (Cygwin/X)" To: cygwin In-Reply-To: <4C3534E6.90505@cwilson.fastmail.fm> References: <4C3215FC DOT 3010309 AT cwilson DOT fastmail DOT fm> <1278402537 DOT 5784 DOT 8 DOT camel AT YAAKOV04> <4C337C6E DOT 2080003 AT cwilson DOT fastmail DOT fm> <1278455320 DOT 4032 DOT 49 DOT camel AT YAAKOV04> <4C33EEC1 DOT 9050600 AT cwilson DOT fastmail DOT fm> <1278519024 DOT 1096 DOT 90 DOT camel AT YAAKOV04> <4C34D3BF DOT 7020404 AT cwilson DOT fastmail DOT fm> <1278548055 DOT 6960 DOT 59 DOT camel AT YAAKOV04> <4C3534E6 DOT 90505 AT cwilson DOT fastmail DOT fm> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Jul 2010 22:39:15 -0500 Message-ID: <1278560355.6960.114.camel@YAAKOV04> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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