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: RFC: cygport cross-compiling APIs


On Mon, 2010-07-12 at 14:41 -0400, Charles Wilson wrote:
> Are we sure about this, given mingw64's express desire to avoid this 
> $prefix -- specifically because "the other mingw" has historically used 
> it, and "the other mingw" has had its preferences enshrined in the 
> upstream gcc source code?

The (proposed?) Fedora mingw64 packages use /mingw as well.

> So by DLL you mean, explicitly, PE/COFF Dynamic Libraries for win32, and 
> NOT the generic "dynamically loaded library" category that can, loosely 
> speaking, include also ELF .so's.

Yes, I mean DLL literally, as in PE/COFF; I use "library" to refer to
the generic, cross-platform concept.

> You mean that if a (shared) library -- whether ".dll" or ".so" -- is 
> built using libtool's -module flag (e.g. shouldnotlink=yes in the .la 
> file), then the .a's (and .dll.a's) are removed?
> 
> I suppose the "linktime symbolic links" often used with ELF shared 
> libraries aren't even created by 'libtool --mode=install' for modules, 
> so that's a non-issue.

If -avoid-version is used -- which it generally should be with -module
-- then libfoo.la produces only a libfoo.so file and no symlinks are
created.  If not, then you still get the .so.X.Y.Z file and .so.X
and .so symlinks, but the latter is usually what is actually dlopen()ed
at runtime.  Either way, the .so must stay, the .a can go, and of course
there is no .dll.a.

> Neato.

No, I have no plans on cross-compiling graphviz.  But there is a native
package in Ports. :-)

> What about $prefix?  Is this handled automatically by cygport (e.g. 
> always /usr, unless $host=mingw* then /mingw?) and can't be overridden?

Correct.

> I'd really like to be able to override $prefix in general, because it 
> would make the gcc-tools-* packages a lot easier.

Are those still needed, with gcc now supporting recent autotools?

> Another argument is similar to the one above: what about other 
> .cygclasses that use these functions?  If I'm required to use 
> docrossbin, I can easily do that in my own .cygport -- but not if I 
> inherit another .cygclass in addition to 'cross', and THAT .cygclass 
> uses the (original) dobin.
> 
> As far as the package .cygport calling dodoc...I think we'll have to 
> take that as it goes. The NOCROSS idea below might help here.

Right now I'm thinking that dodoc should ignore CROSS_HOST.

> Well, there's the mingw-runtime stuff, which is still used/needed by 
> gcc3's -mno-cygwin.

IIUC Corinna correctly, w32api would stay and we would add a
mingw-w32api.

> Plus there's the particular version of w32api that 
> is used by cygwin's own gcc (and gcc3's -mno-cygwin) and is installed 
> into /usr/include/w32api + /usr/lib/w32api.

More importantly, mingw-runtime would move from /usr/{include,lib}/mingw
to /usr/i686-pc-cygwin/sysroot/mingw/{include,lib}, which would break
gcc3 -mno-cygwin, unless we provide symlinks.  If we build a
i686-pc-mingw32-gcc-4.5, can we just get rid of gcc3 -mno-cygwin?
Pleeeease?

> I assume this version would NOT be compiled using the i686-pc-mingw32 
> toolchain, but instead by the cygwin one (e.g. its cygport -- if it is 
> actually built USING cygport -- wouldn't inherit cross), so that's 
> probably not an issue.

Right, the w32api going into /usr/{include,lib}/w32api would be built
native.

>    the mingw-{zlib,bzip2,xz,libgcrypt,libgpg-error} stuff
>       -- should be handled by the new cross cygclass with no problems

Is compiling setup.exe with mingw64-i686 an option?  If so, we'll need
mingw64-i686 ports of those as well.  Either way, those should all be
cygport-able.

>    the tools in the cygwin package, like strace.exe and cygcheck.exe
>       -- no changes; handled by cygwin gcc with -nostdlib? and not
>          built using cygport anyway.
> 
> So...there aren't that many cross-compiled packages that are part of the 
> cygwin distribution -- and few would use any additional cygclasses, 

No, I don't think we should be accepting every library *in the distro*
compiled for every toolchain on the planet.  But by covering the basics
properly, cygport should still be usable for that purpose by individual
users.

> I think, on balance, it'd be better to have the existing do* scripts 
> change their behavior when 'cross' has been inherited, rather than 
> requiring the use of a separate set of functions.

Ack.

> The best of all worlds would be to have a local override, that can be 
> set per-command:

I have already thought of a couple of cases where it might make sense to
install outside of sysroot, although that should still be a fringe case.
If we agree that do* should work under the sysroot, then whatever we
decide for handling these can come later w/o breaking API.

> This scheme can't address the issues related to OTHER inherited 
> cygclasses which use the do* commands.  But then, we probably don't care 
> about that very much.  .cygclasses are supposed to be black boxes that 
> 'just work'(tm); their internal operation shouldn't be second guessed.

No, they shouldn't, otherwise it's impossible to keep any semblance of
API stability.

> Remember that in mingw64-speak, the "mingw64-crt-headers" is a 
> completely separate package than "mingw64-crt-lib" -- there's no 
> "top-level" configure typing them together, AFAIR; so it'd be rather 
> difficult to munge them together into a single package named 
> "mingw64-*-runtime".

The upstream "mingw-w64-snapshot" source packages actually contain both
with a top-level configure.  The only reason to do one without the other
is when bootstrapping; I see no need to artificially split them for the
distro.

> Or, for that matter, splitting mingw64-$CPU-gcc into separate languages. 
> I *really* don't want to have to download Fortran, ObjC, (and perhaps 
> Ada and java?) when all I really want is C++.

I would have no objections to splitting out gcc into core/g
++/objc/fortran subpackages (provided that the DLLs go together with
their respective compiler), I'm just not bothering with that right
now.  

As for Ada and Java, JonY didn't enable those either.  Apparently Java
is "extremely slow" with SJLJ, although I don't know if that means GIJ
(which we don't need in a cross-compiler) or GCJ-compiled code.

> Finally, you appear to be deliberately precluding any POSSIBILITY of 
> providing a multilib gcc. I know cygport can't yet support it, but we 
> might find it necessary or desirable down the road to add that support. 

I've heard multilib called a lot of things on #mingw-w64, but
"necessary", "practical", or "stable" were not among them.  It might be
nice for hand-compiling small stuff, but from the packaging perspective,
once you have a separate i686 cross-compiler, it just doesn't make
sense.  It's not as if most (any?) packages make it any easier to build
multilib then building i686 and x86-64 separately.

> Which is why I say, *defer* this until later -- don't try to solve these 
> multilib problems right now.  But also, don't deliberately preclude 
> various possible solutions, by package nomenclature whose that isn't 
> expressive enough, or poorly chosen sys-root $prefix values.

On any native multilib system, you still have only one $prefix, period.
You just have multiple lib* directories.  Same here.

> Now, as I said above, maybe the correct answer is "don't try to split it 
> up: the multilib "mingw64-crt-lib" should include whatever is necessary 
> in both sys-root/prefix/lib and sys-root/prefix/lib$MULTI; ditto 
> sys-root/prefix/bin and ...bin$MULTI, all in one happy package. Ditto 
> for the other "core" components of a toolchain.
> 
> If you do that, then mingw64-$CPU-$PKG would work fine (but might be a 
> little confusing, since it could contain $OTHER-CPU stuff).

Exactly, why do they need to be separated at all?  If they're both meant
to be used by one toolchain and installed in one sysroot, just package
them together.

IOW mingw64-x64-zlib doesn't necessary mean just "a Win64 zlib" but "a
zlib that can be used with mingw64-x64-binutils/gcc", compiled against
whichever ABI(s) mingw64-x64 supports and installed in the mingw64-x64
sysroot.  If the latter are multilib, then so can the former be without
dicing up each package into a million pieces.

> Right, well, I'll obviously handle the stuff I currently maintain: the 
> mingw-{zlib,bzip2,xz,libgcrypt,libgpg-error} stuff. And I assume DaveK 
> would do the mingw-{binutils,gcc} ones, since he's already volunteered 
> for that (unless he's changed his mind?).

BTW, weren't you going to check mingw.org gcc for patches and options so
I could cook up .cygport drafts for those as well?

> Ack. For now, and maybe forever wrt mingw.org $target and mingw64 
> $target(s).  Probably, tho, the no-multilib "policy" will be hard to 
> maintain if cygwin starts shipping cross compilers targeting other 
> $hosts like Solaris, IRIX, etc.  Not that I have any burning desire to 
> ship or maintain those myself -- but somebody out there might volunteer 
> in the future.
> 
> I just don't like deliberately hardcoding a possibly-subject-to-change 
> policy discussion into a difficult-to-reverse nomenclature.

If we don't sub-split the multilib ABIs then there's no problem.

> No, I disagree with this.  mingw-bzip2 provides, in toto, the DLL, 
> headers, static/link libs, and utility apps.
> 
> Nobody who ONLY wants to build setup.exe using the new cross compiler 
> cares about the DLLs (because setup.exe uses -static) nor do they care 
> about the apps.  OTOH, those elements ARE part of the cross compiled 
> "sys-root" that, if someone were to 'repackage' for independent 
> deployment selected contents of sysroot/$prefix/bin, they would need. 
> Since we ship a mingw-bzip2 complex of packages, why should (a) the 
> first group have to download and install everything, if they only need 
> the headers and static libs but everything were bundled into one 
> package, or (b) the second group have to recompile mingw-bzip2 
> themselves if we strip the "unnecessary" parts from a single mingw-bzip2 
> package?

Remember that I'm looking at *all* cross-compiling scenarios here.  On
most other platforms, a -devel package absolutely requires its
corresponding lib package, because the unversioned .so is just a symlink
to the real lib; without the real lib, the symlink is worthless.  Even
on PE platforms where we have import libs, the DLLs aren't required to
link, but once you have linked with them it's nice to have them around
already so you can use your new program.  Hence, I make my -devel
packages depend on their libs on Cygwin as well.

Since, from the distro perspective, the purpose of including
cross-compiled libraries is so that you can build against them, not run
them (since in most combinations execution is not possible).  IOW,
unlike native packages, the "-devel" is of primary importance, and if
once you install the -devel you need the lib as well, then you already
have (almost) everything, so what point is there to splitting them?

So yes, we install everything in one package.  Will there perhaps be a
little extra in the package?  Possibly, but we shouldn't be talking
about so many cross-compiled packages *in the distro* that it should
make a real difference.

FWIW, the Fedora mingw64 packages don't have split -devel packages
either.

> The same argument holds with regards to the gcc language runtimes. 
> Maybe somebody is interested not in cross compiling anything themselves, 
> but using (from a private, or corporate) setup.exe repo some native 
> win32 tools that are meant to be installed into a cygwin-hosted mingw 
> sysroot.  Shouldn't they be able to get our libgcc_s-1-sjlj.dll without 
> installing the entire cross compiler?

Ditto.  The purpose of a cross-gcc isn't to get the libs -- you would
get those from the distro on which you're running the cross-compiled
executable -- but to build against them.  The DLLs are just along for
the ride.


Yaakov



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