This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cygport cross-compiling beta1
On 20/07/2010 05:53, Charles Wilson wrote:
> But at SOME point, SOME part of what you've built on $host is supposed
> to be used, eventually, by somebody, on $target, right?
>
> Where should THAT live?
On the target?
> Then package an /etc/profile.d script that appends or prepends to
> MANPATH and INFOPATH.
>
> Or assume some modicum of intelligence on the part of people with the
> gumption to actually install a *cross compiler*, and allow them to
> manually set INFOPATH/MANPATH as appropriate when they are using a given
> cross tool.
Either of these work for me, but each compiler should definitely have its
own docs in its own prefix IMO.
>>> Also, this packaging oddity:
>>> mingw64-x86_64: usr/x86_64-w64-mingw32/lib64/libiberty.a
>> x86_64-w64-mingw32 is potentially a multilib arch, hence the lib64. If
>> the gcc were actually built multilib, you'd see a lib32 and lib64.
>>
>>> mingw64-i686: usr/i686-w64-mingw32/lib/lib32/libiberty.a
>> You mean /usr/i686-w64-mingw32/lib/libiberty.a? The only way you would
>> get lib32/libiberty.a (not lib/lib32) is with multilib, which I disabled
>> in my builds.
Re: libiberty.a, I have no idea why we even install that. We don't install
the headers, and it has no fixed defined API or versioning, so it's basically
useless. I wouldn't worry too much about where it ends up!
>>> However, given the dependency structure of the gcc3 packages, this means
>>> you pretty much have to also remove, using setup,
>>> gcc-core
>>> gcc-g++
>>> gcc-java
>>> gcc-objc
>>>
>>> Note that this conflict means that the current gcc-mingw* packages (and,
>>> thus, the gcc 3.x packages) conflict with the new mingw-gcc-* and
>>> mingw-binutils-* packages. Also, this may have implications for the
>>> upgrade process, when the "real" mingw32-gcc cross toolchain is
>>> released. Even if we mark the gcc (3) packages obsolete, we probably
>>> have to repackage them and their gcc-mingw* friends to fix this upgrade
>>> problem, and perhaps relieve the conflict. Somehow?
>> We can just remove the gcc-mingw* deps from gcc3*. But the bigger
>> question is, do we still *need* gcc3 in the distro?
Yes, we get mails every now and again where someone's relying on it to build
a legacy app, I don't want to pull it.
> Once we can build setup.exe with gcc4, then I don't believe we *need*
> it. And we can *definitely* get rid of mingw-gcc*; at that point, gcc
> -mno-cygwin breaks badly, and we get to say "it's been deprecated for
> over a year, and now it is no longer supported. Use this spiffy new
> cross compiler".
>
> But...somebody out there might have (cygwin) code that doesn't compile
> with gcc4. They ought to fix their code, but...this is not an ideal world.
Yeah, this is tricky. I don't mind if we end up telling people they can
have *either* gcc-3 *or* x-mingw-gcc4 but not both at the same time. I guess
it's worth testing if gcc-3 -mno-cygwin still works with up-to-date mingw
cross-binutils and libs installed in place of the /usr/i686-pc-mingw32 symlinks.
cheers,
DaveK