Re: [RFU] vorbis-tools 1.4.0-1
On Jul 8 11:01, David Rothenberger wrote: > Please leave 1.2.0-2 as previous. > > wget -x -nH --cut-dirs=2 \ > > http://home.comcast.net/~david.rothenberger/cygwin/vorbis-tools/vorbis-tools-1.4.0-1-src.tar.bz2 > \ > > http://home.comcast.net/~david.rothenberger/cygwin/vorbis-tools/vorbis-tools-1.4.0-1.tar.bz2 > \ > http://home.comcast.net/~david.rothenberger/cygwin/vorbis-tools/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: cppcheck-1.44-1
On Jul 11 08:14, Chris Sutcliffe wrote: > Please upload: > > --- > > wget -x -nH --cut-dirs=1 \ > http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.44-1.tar.bz2 \ > http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.44-1-src.tar.bz2 > > --- > > Keep cppcheck-1.43-1 as previous and all others can be removed. Uploaded and 1.42-1 removed. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: nasm-2.08.02-1
On Jul 12 00:50, Dean Scarff wrote: > Upstream release, please upload. > > wget -x -nH --cut-dirs=2 \ > http://scarff.id.au/file/cygwin/nasm/nasm-2.08.02-1-src.tar.bz2 \ > http://scarff.id.au/file/cygwin/nasm/nasm-2.08.02-1.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] libtheora - Xiph.Org's video codec
On Jul 6 16:40, David Rothenberger wrote: > I'd like to package libtheora. It is part of Debian Stable[1]. > [...] > download: > -- > wget -x -nH --cut-dirs=2 \ > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/setup.hint \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoraenc1/setup.hint > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoraenc1/libtheoraenc1-1.1.1-2.tar.bz2 > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoradec1/setup.hint > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoradec1/libtheoradec1-1.1.1-2.tar.bz2 > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora0/setup.hint > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora0/libtheora0-1.1.1-2.tar.bz2 > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-devel/setup.hint > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-devel/libtheora-devel-1.1.1-2.tar.bz2 > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-1.1.1-2.tar.bz2 > \ > > http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-1.1.1-2-src.tar.bz2 Looks good to me. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release (Dave Korn we need you)
On Jul 8 08:25, Charles Wilson wrote: > On 7/8/2010 3:22 AM, Corinna Vinschen wrote: > > On Jul 7 18:24, Christopher Faylor wrote: > >> [...] > >> Whether we use w32api in the cygwin tree or from somewhere else really > >> doesn't matter as long as Cygwin builds. > > > > That's why I'd like to know if Cygwin builds with w32api from the > > mingw64 project. > > Have you checked with Red Hat's lawyers concerning the use of mingw64's > w32api to build their cygwin-based products? That's something I'll doo as soon as we really intend to switch the Cygwin build to mingw64's w32api. Right now, what I get from all the gory details, it's not that easy to keep mingw64's w32api headers and libs apart from the mingw headers and libs anyway. > > However, I won't object against having a version for the 64 bit gcc > > hidden in the cross-compiler tree, if there's no way around it. > > But *if* there's a way to keep just a single version, it should be > > exploited. > > I don't get this. There are three reasons to be concerned about multiple > copies -- even if they are identical (which in this case they are not > and can't be, esp. 64bit vs 32bit implibs). > 1) disk space > 2) things that should be identical (like headers for the > OS's API) out of sync, or keeping them deliberately different > 3) end user confusion You're missing number 4. Cygwin and Mingw are targeting the same underlying "real" target, which is Windows. Both systems use different approaches and both have their own set of libs and headers which only make sense in their own environment. But underneath they both run on Windows. For that reason my POV is that w32api is an intrinsic part of the system and that's why it belongs into /usr/include and /usr/lib. IMHO. If there's no way around it, I don't mind if we have multiple w32api, one for the system and one for each mingw cross compiler. I don't mind the disk space. I don't know beforehand which solution will result in more or less user confusion. So just go ahead. As for the path issue, I'd prefer to get a layout which closely resembles the Fedora mingw filesystem layout as in http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RFC: cygport cross-compiling APIs
I think I'm getting close to nailing down cross-compiling support in
cygport.
Throughout, the prefix=/usr assumption has been removed; *-*-mingw*
hosts use /mingw, everything else is /usr for now. (Anyone know any
specific systems where that's not the case?) Cross-compiled packages
are properly strip(1)ed with the correct binutils. Libtool fixup puts
non-native DLLs into $CROSS_HOST/prefix/bin if not already there, and
doesn't move non-PE libs but still removes static modules. Also,
package dependencies for mingw* and linux* cross-compiles are supported.
While I was at it, some initial work was done to make adapting to a
possible future x86_64-pc-cygwin easier as well.
Here's what the API looks like so far:
toolchain.cygclass: for building binutils/gcc/gdb (cross-)compilers
* TOOLCHAIN_TARGET: the target triplet (defined in .cygport BEFORE
"inherit toolchain")
* toolchain_compile(): runs cygconf with --build/host/target and
--with-sysroot, followed by cygmake
* src_compile(): just toolchain_compile; no cygautoreconf (these
packages don't autoreconf easily)
cross.cygclass: for cross-compiling
* CROSS_HOST: the host triplet (defined in .cygport BEFORE "inherit
cross")
* CROSS_SYSROOT: the host sys-root (== /usr/${CROSS_HOST}/sys-root)
* CC/CXX/F77/FC are $host-prefixed
* PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSROOT_DIR are set for pkg-config
* cygconf automatically adds --build/host/target
I implemented the cygconf hook instead of a separate cross_compile() so
that other cygconf-based cygclasses would benefit. For example, a
mingw64-x86_64-glib2.0 would "inherit cross gnome2", where
gnome2_compile calls cygconf.
Right now my dilemma is with the cross.cygclass install functions. I'm
not sure whether cyginstall/do*/new* should just flip personality to
install under $CROSS_SYSROOT (much like cygconf does), or whether to
implement separate docross{bin,include,lib,...} functions. My reason
for considering the former is that it would reduce duplicate code and
avoid easy mistakes (e.g. installing cross-compiled stuff into native
directories). It would also make it easier to take a native .cygport,
rename it, define CROSS_HOST and inherit cross, and build. OTOH I'm not
sure whether the more manually-controlled dodir, exe/insinto, doexe/ins,
and newexe/ins should also imply $CROSS_SYSROOT or not: IOW, is there
any case where a cross-compiled package would legitimately install
anything outside of $CROSS_SYSROOT (besides the standard docs). I also
wonder if that would itself be confusing.
As for the package naming scheme -- which is not being enforced by
cygport itself -- my thoughts are OS[-CPU]-PACKAGE, IOW:
mingw64-i686-binutils
mingw64-i686-gcc
mingw64-i686-pthreads
mingw64-i686-runtime
mingw64-i686-zlib
mingw64-x86_64-binutils
mingw64-x86_64-gcc
mingw64-x86_64-pthreads
mingw64-x86_64-runtime
mingw64-x86_64-zlib
linux-i686-binutils
linux-i686-gcc
linux-i686-glibc (not built yet; borrowed from Fedora for bootstrapping)
linux-i686-kernel-headers (ditto)
linux-i686-zlib
(none of these are built yet)
mingw-binutils
mingw-bzip2
mingw-gcc
mingw-runtime
And so on. For simplicity, none of these are multilib, and the
conflicting binutils/gcc locales/info/etc. are removed, for reasons
stated in earlier discussions.
Note that I'm *not* breaking out separate lib/devel packages, because if
you think about the reasons for these splits with native packages,
within the context of cross-compiling they doesn't make sense.
Comments welcome, but let's not bikeshed this. Hopefully this week or
next I can document this all, clean up the patches, and publish a beta
cygport and .cygport drafts.
Yaakov
Re: gcc4: next release (Dave Korn we need you)
On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: > That's something I'll doo as soon as we really intend to switch the > Cygwin build to mingw64's w32api. Right now, what I get from all the > gory details, it's not that easy to keep mingw64's w32api headers and > libs apart from the mingw headers and libs anyway. No, it's not. > You're missing number 4. Cygwin and Mingw are targeting the same > underlying "real" target, which is Windows. Both systems use different > approaches and both have their own set of libs and headers which only > make sense in their own environment. But underneath they both run on > Windows. For that reason my POV is that w32api is an intrinsic part of > the system and that's why it belongs into /usr/include and /usr/lib. > IMHO. OTOH there are a number of packages out there that see in the default include path and say, "Oh, this must be a Windows system! Let's use winsock/GDI/etc." which is often -- but not always -- incorrect on Cygwin. w32api may not be limited to cross-compiling, but having it in the default search path isn't always great either. > If there's no way around it, I don't mind if we have multiple w32api, > one for the system and one for each mingw cross compiler. I don't > mind the disk space. I don't know beforehand which solution will > result in more or less user confusion. So just go ahead. This will be much easier from the packaging perspective. > As for the path issue, I'd prefer to get a layout which closely > resembles the Fedora mingw filesystem layout as in > http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. That is what I'm working with now. Yaakov
Re: gcc4: next release (Dave Korn we need you)
On Jul 12 05:25, Yaakov S wrote: > On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: > > You're missing number 4. Cygwin and Mingw are targeting the same > > underlying "real" target, which is Windows. Both systems use different > > approaches and both have their own set of libs and headers which only > > make sense in their own environment. But underneath they both run on > > Windows. For that reason my POV is that w32api is an intrinsic part of > > the system and that's why it belongs into /usr/include and /usr/lib. > > IMHO. > > OTOH there are a number of packages out there that see in > the default include path and say, "Oh, this must be a Windows system! > Let's use winsock/GDI/etc." which is often -- but not always -- > incorrect on Cygwin. w32api may not be limited to cross-compiling, but > having it in the default search path isn't always great either. Yeah, everything comes with a price tag. > > As for the path issue, I'd prefer to get a layout which closely > > resembles the Fedora mingw filesystem layout as in > > http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. > > That is what I'm working with now. Nice. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
On 7/12/2010 1:49 AM, Yaakov (Cygwin/X) wrote: > On Sun, 2010-07-11 at 14:43 -0400, Charles Wilson wrote: >> However, it's easier to walk before you run, so how about we get >> everything nice and pretty with two (three, counting mingw.org) separate >> non-multilib tool chains. Each would be built with sysroots, and given >> the way (I now discover) sysroots *must* work, we would thus end up with; > > Since you keep mentioning mingw.org, AFAICS they still ship gcc-3.4.4, > which we (sort of) have already. No, their current release is 4.5.0, and the previous release was 4.4.0. They have had 'testing' releases of 4.3.0 and 4.2.1, but those never achieved sufficient stability to be promoted as (what we would call) 'curr:'. > Is that what you are referring to, or > do you simply mean the latest binutils and gcc built for target > i686-pc-mingw32? If the latter, are any patches or specific configure > options necessary (besides using dw2 exceptions instead of sjlj)? Patches were required for 4.2.1 and 4.3.0. However, I believe mingw.org's 4.4.0 and 4.5.0 were based on upstream gcc sources without modification, just configured for i686-pc-mingw32. I'll d/l the -src and check later. And, of course, mingw.org's compilers are tied to the winsup/w32api headers and libs, and to the winsup/mingw mingw-runtime. >> [1] The official --prefix with which cross-compiled clients, built >> using the mingw.org toolchain, should be configured. Dunno whether >> this should be the /mingw (which is what mingw.org uses for its >> stuff, modulo dosify concerns), or something we decide on our own, >> like --prefix=/mingw32 or --prefix=/mingw.org. >> >> [2] Whatever prefix we choose to assert that cross-compiled clients, >> built using the 32bit-flavor mingw64 toolchain, should be >> configured. I think the mingw64 guys recommend using anything >> EXCEPT /mingw -- because they don't want to conflict with stuff >> from mingw.org (or, more accurately, they don't want to run the >> risk that stuff from mingw.org would conflict with THEM) >> >> [3] Whatever prefix we choose to assert that cross-compiled clients, >> built using the 64bit-flavor mingw64 toolchains, should be >> configured. I'm partial to --prefix=/mingw64. > > Are you sure about this? The /mingw prefix is hard-coded into all > gcc/config/i386/t-mingw*. And that's specifically why mingw64 doesn't want to use it, AND why *mingw64* recommends that, if you install multiple versions of the (non-cross) mingw and/or mingw64 compilers, that NONE of them go into /mingw (C:\MinGW, D:\MinGW, etc) -- because then ALL of them will find whatever lucky version happens to get installed there. (IIRC, they acknowledge that you'd then have to specify explicitly -L and -I options even for native compilers, but that's not an issue for us, right? For cross-compilers, our users would have to do that anyway, correct?) Obviously, this conflicts with *mingw.org*'s recommendations. I don't know if this disagreement would affect our decisions, because (a) all three toolchains would have different sysroots, so toolchain A's "/mingw" sysroot $prefix would be at /usr/$target-A/sys-root/mingw, while toolchain B's sysroot $prefix "/mingw" would be at /usr/$target-B/sys-root/mingw -- so there would be no conflict. However, if compiled clients were to be (re)packaged and installed by third party users without cygwin...then they'd all "want" to go in /mingw if all of our toolchains used .../sys-root/mingw. And then we run headlong into that mingw64/mingw.org disagreement. So...my "compromise" was to follow mingw.org's recs for the mingw.org toolchain, and mingw64's recs for theirs. (But I held out the possibility, for mingw.org, of specifically choosing a different sysroot $prefix, such as /mingw32, instead -- just to avoid "privileging" one toolchain over the others.) Honestly, I think we just have to experiment to see which way works best -- including *using* the toolchains to compile clients, and then install the results on a virgin machine in various locations. >> And maybe JonY doesn't even care much about multilib. > > From the POV of building other packages, trying to build any package > simultaneously for a multilib setup is a lot of work, and cygport is > certainly not up to that right now. I think it should suffice if we > provide both i686 and x86_64 mingw64 compilers. I was thinking of client packages that might not be fully 64bit ready; e.g. some utility apps need to be compiled using -m32, but most of the package is -m64-ready. In this case, you'd want to configure using the 64bit toolchain, but set a per-app CFLAGS that include -m32 for the few apps that aren't 64bit ready. AFAIK, autotooled packages don't let you specify a per-target CC, so you can't easily use a different (e.g. i686-*) compiler. Now, I don't KNOW that any projects like this exist, but that was my thinking in "favor" of a multilib 64bit toolchain. But t
Re: gcc4: next release (Dave Korn we need you)
On 7/12/2010 8:02 AM, Corinna Vinschen wrote: > On Jul 12 05:25, Yaakov S wrote: >> On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: >>> You're missing number 4. Cygwin and Mingw are targeting the same >>> underlying "real" target, which is Windows. I wasn't actually "missing" it; I just considered this part of #2, but didn't fully express it: "things that should be identical...out of sync". E.g. if it's all one OS, then all compilers should use identical headers. And, if they are (or should be) identical, then why not have a single common location? I understand that argument, but we're not sure they all really CAN be identical (e.g. the 64bit libs vs. the 32bit ones; the possible issue with mingw64 headers' provenance, etc). So, if there might be SOME differences, then... It makes sense to me, then, that each toolchain should provide, in a private area (e.g. sysroot), that version of the w32api libs and headers with which it has been tested. Rather than a hodge-podge where "these two cross toolchains have their own custom w32api headers that they share between them but separate copies of the w32api libs; /that/ one has a custom w32api that isn't shared with anybody, but /this/ one shares w32api with cygwin's gcc..." Ick.) >>> Both systems use different >>> approaches and both have their own set of libs and headers which only >>> make sense in their own environment. But underneath they both run on >>> Windows. For that reason my POV is that w32api is an intrinsic part of >>> the system and that's why it belongs into /usr/include and /usr/lib. >>> IMHO. I assume that you were not proposing to move the w32api headers from /usr/include/w32api/ into /usr/include/ proper, nor the libs from /usr/lib/w32api into /usr/lib proper, were you? If the cross toolchains provide their own w32api (and mingw-runtime) [or, for 64bit, "mingw64-crt-headers" and "mingw64-crt-lib"], then...the only remaining user of our current w32api api package is cygwin's own gcc (all versions). And the only remaining user of our current mingw-runtime packages is cygwin's gcc3 (and anything that might require /usr/bin/mingwm10.dll). So, after all of the cross compilers are deployed, we might think about what optimizations we could make with regards to how the non-toolchain-sysroot-specific w32api and mingw-runtime packages are...packaged. (The answer may be: make no changes.) But I don't want to start that discussion too early, so let's table it for now. >> OTOH there are a number of packages out there that see in >> the default include path and say, "Oh, this must be a Windows system! >> Let's use winsock/GDI/etc." which is often -- but not always -- >> incorrect on Cygwin. w32api may not be limited to cross-compiling, but >> having it in the default search path isn't always great either. > > Yeah, everything comes with a price tag. Yep. I have to keep reminding people that #including will cause _WIN32 to be defined, and that #ifdef _WIN32 does not, actually, mean !CYGWIN... -- Chuck
Re: RFC: cygport cross-compiling APIs
On 7/12/2010 6:19 AM, Yaakov (Cygwin/X) wrote:
I think I'm getting close to nailing down cross-compiling support in
cygport.
Great! (Is your current state checked in to git master or some other
branch?)
Throughout, the prefix=/usr assumption has been removed; *-*-mingw*
hosts use /mingw, everything else is /usr for now.
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?
Do the guys at #mingw64 have any comment on the "proper" prefix that
cross compilers should use underneath a sysroot?
(Anyone know any
specific systems where that's not the case?) Cross-compiled packages
are properly strip(1)ed with the correct binutils. Libtool fixup puts
non-native DLLs into $CROSS_HOST/prefix/bin
I ask the following question for clarification only:
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.
I assume so, because that's the only interpretation that doesn't
conflict with this statement:
if not already there, and
doesn't move non-PE libs
Now, for the next bit:
but still removes static modules.
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.
I ask the preceding question for clarification only.
Also,
package dependencies for mingw* and linux* cross-compiles are supported.
While I was at it, some initial work was done to make adapting to a
possible future x86_64-pc-cygwin easier as well.
Neato.
Here's what the API looks like so far:
toolchain.cygclass: for building binutils/gcc/gdb (cross-)compilers
* TOOLCHAIN_TARGET: the target triplet (defined in .cygport BEFORE
"inherit toolchain")
* toolchain_compile(): runs cygconf with --build/host/target and
--with-sysroot, followed by cygmake
* src_compile(): just toolchain_compile; no cygautoreconf (these
packages don't autoreconf easily)
Sounds good.
cross.cygclass: for cross-compiling
* CROSS_HOST: the host triplet (defined in .cygport BEFORE "inherit
cross")
* CROSS_SYSROOT: the host sys-root (== /usr/${CROSS_HOST}/sys-root)
* CC/CXX/F77/FC are $host-prefixed
* PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSROOT_DIR are set for pkg-config
* cygconf automatically adds --build/host/target
What about $prefix? Is this handled automatically by cygport (e.g.
always /usr, unless $host=mingw* then /mingw?) and can't be overridden?
I'd really like to be able to override $prefix in general, because it
would make the gcc-tools-* packages a lot easier.
Also, particularly with respect to the mingw* cross compilers, I'm
unsure that all three should all use sys-root/mingw/. Again, what do
the #mingw64 folks recommend in this situation?
I implemented the cygconf hook instead of a separate cross_compile() so
that other cygconf-based cygclasses would benefit. For example, a
mingw64-x86_64-glib2.0 would "inherit cross gnome2", where
gnome2_compile calls cygconf.
I see.
Right now my dilemma is with the cross.cygclass install functions. I'm
not sure whether cyginstall/do*/new* should just flip personality to
install under $CROSS_SYSROOT (much like cygconf does), or whether to
implement separate docross{bin,include,lib,...} functions. My reason
for considering the former is that it would reduce duplicate code and
avoid easy mistakes (e.g. installing cross-compiled stuff into native
directories). It would also make it easier to take a native .cygport,
rename it, define CROSS_HOST and inherit cross, and build.
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.
OTOH I'm not
sure whether the more manually-controlled dodir, exe/insinto, doexe/ins,
and newexe/ins should also imply $CROSS_SYSROOT or not:
Well, you know me: I'm always in favor of giving the end user of cygport
more power, and less authoritarian control by cygport itself.
Boat-on-water with channel markers, rather than car-on-road with
concrete guardrails.
However, in THIS case...see below.
IOW, is there
any case where a cross-compiled package would legitimately install
anything outside of $CROSS_SYSROOT (besides the standard docs). I also
wonder if that would itself be confusing.
Wel
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?
Plase?
> 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
Re: RFC: cygport cross-compiling APIs
On 7/12/2010 6:06 PM, Yaakov (Cygwin/X) wrote:
> 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.
Proposed by whom? Some member of the mingw64 project, or outsiders like
us? Again, what do the actual #mingw64 folks say about this?
>> 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?
JonY just mentioned that he thought a specific *libtool* epoch might be
required -- but I think that's because he was trying to use autoreconf,
which IMO isn't (yet) appropriate for gcc/binutils...heck, it's not
appropriate for anything in the sourceware src/ repository.
gcc-4.6 development apparently still requires autoconf-2.64, while the
"normal" cygwin autoconf is at 2.65 (and should soon be moving to 2.66).
gcc requires automake-1.11.1, and our "regular" automake1.11 is 1.11.1
so at least that matches.
But the autoconf difference means we still need gcc-tools-epoch2. And
gcc-tools-epoch1 will never go away, but since it's frozen anyway we
never need to rebuild IT.
>> 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.
I don't really care either way about that one. What about things
associated with $sysconfdir and $localstatedir? (e.g. /etc and /var are
usually "outside" of $prefix). For cross (clients), suppress
prep_etc_defaults, and assume $sysconfdir and $localstatedir are
underneath $prefix?
>> 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},
All of this agrees with my understanding.
> 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?
> Plase?
No argument from me. There will be weeping, wailing, and gnashing of
teeth on the list, tho.
>> 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.
Ack.
>>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.
Hm. A 64bit version of setup.exe; interesting. I don't mind providing
the additional packages for that; the list of setup's dependencies isn't
THAT long.
>>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.
Right. Setup's dependencies, IMO, serve as a sufficient "proof of
concept" that the cross compiler toolchains work.
>> 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.
True. This is not the sort of thing you'd want to do automatically, but
the ability to override might be important in some cases. None spring to
mind right now, but I'm sure they exist.
> If we agree that do* should work under the sysroot, then whatever we
> decide for handling these can come later w/o breaking API.
OK.
>> This scheme can't address the issues related to OTHER inheri
Re: RFC: cygport cross-compiling APIs
On Mon, 2010-07-12 at 22:45 -0400, Charles Wilson wrote: > I don't really care either way about that one. What about things > associated with $sysconfdir and $localstatedir? (e.g. /etc and /var are > usually "outside" of $prefix). For cross (clients), suppress > prep_etc_defaults, and assume $sysconfdir and $localstatedir are > underneath $prefix? IIUC /etc and /var only belong outside of $prefix when $prefix == /usr. Any other $prefix and they go back underneath, so that's what I'm doing. > No argument from me. There will be weeping, wailing, and gnashing of > teeth on the list, tho. What else is new? > Hm. A 64bit version of setup.exe; interesting. I don't mind providing > the additional packages for that; the list of setup's dependencies isn't > THAT long. No, I said i686-mingw64. I easily cross-built setup's deps for that toolchain then tried to build setup, but the mingw64 DDK headers are clearly not up to the task; they #include headers which do not exist and apparently some headers are missing. setup.exe needed some adjustments as well even as far as I did get. To be continued. > > 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? > > See attached. Short version: no patches to the source code, but some > odd build techniques. > > One thing we probably don't care about: mingw.org uses a "forward.c" app > to emulate hardlinks (and to avoid MSYS's fallback of "make a separate > copy" for symlinks) of very large .exe's. > > configure options: > > cd $builddir && > $srcdir/configure \ > --enable-languages=c,c++,ada,fortran,objc,obj-c++ \ > --disable-sjlj-exceptions\ > --with-dwarf2\ > --enable-shared \ > --enable-libgomp \ > --disable-win32-registry \ > --enable-libstdcxx-debug \ > --enable-version-specific-runtime-libs \ > --disable-werror \ > --build=mingw32 \ > --prefix=/mingw > > Java is not yet ready, but is promised for later. Werror is disabled > because there are some unaviodable warnings in the Ada build. Does anyone actually *use* Ada? (/me promptly ducks.) > Technically, the mingw.org folks say the only cross compilers they > support are ones built using this tool: > > http://sourceforge.net/projects/mingw/files/Cross-Hosted%20MinGW%20Build%20Tool/x86-mingw32-build-1.0.1-rc1/x86-mingw32-build-1.0.1-sh.tar.bz2/download > > but...we probably would provide support for "our" cross compiler right > here, anyway. And we can probably coordinate "our" build closely enough > with the mingw.org folks that they would likely "bless" our version, too. We should definitely be coordinating patches and configure options so that our compiler is actually compatible to theirs. Whether or not they "bless" is up to them. > E.g. I want to have a package: > > chucks-tools-VER-REL that has > requires: mingw64-i686-libstdc++6 > > Why is this verboten, when all it takes is a little cygport magic no > different that any of our other 500 native cygwin packages, or your > other 2000 cygwin ports packages? IOW you want to make a mingw mini-distro driven by setup.exe. That's IMO not within the realm of the *Cygwin* distribution, nor should it be. > Again, this boils right back down to the fact that here, our Host > platform can simultaneously execute applications (and libraries) from > both the $host and the $target. So therefore we should change the distro into some Cygwin/MinGW hybrid where anything goes as long as it's PE? So why not put the DLLs in /usr/bin? Hey, throw in DJGPP while you're at it. You could even convince GCC to treat them all like a m32/m64 multilib... ... Wait, sound familiar? It was called "-mno-cygwin". Yes, we used to do just that, and IT DIDN'T WORK. And even worse, people got confused. So now we're moving *away* from that, and for good reason. Sorry, but no thanks. MinGW's place within the distro should be for cross-compiling. > Well, it does appear that we are at loggerheads. You insist that > cygwin/mingw is EXACTLY the same as linux/mingw or solaris/irix or any > other combination; I say there is a significant difference between > cygwin/mingw and any other host/target combination, and that difference > makes it wise for use to make certain, minor, accommodations. > > Like, for instance, simply splitting runtime DLLs -- even i686-mingw32 > or x86_64-mingw32 ones -- into separate installable packages JUST LIKE > we do for native cygwin DLLs. I simply can't believe you're digging > your heels in over two lines of cygport(5) code and an extra .hint file > -- simply for the sake of treating a cygwin-hosted mingw compiler > EXACTLY like a linux-hosted one. > > cygwin != linux -- *especially* when it comes to runtime interactions > with win32. >From the website: "Cygwin is a Linux-like environment for Windows." The point is that Cygwin should strive to be like Linux wherever
