This is the mail archive of the cygwin-apps 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 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



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