Re: Possible cygport bug with cross compiles
On 9/1/2010 1:44 AM, Yaakov (Cygwin/X) wrote: On Tue, 2010-08-31 at 17:34 -0400, Charles Wilson wrote: When testing JonY's mingw64 compiler, I found that often the include files ended up in the wrong directory. Often? As in, the ones that inherit toolchain are fine. The ones that inherit cross are not; they put the include files under .../sys-root/mingw/${host_triple}/include rather than the location expected by the compiler, which is .../sys-root/mingw/include --- and therefore, need the extra rule in src_install. mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX} The reason for that is the *upstream* mingw-w64 Makefiles install to $prefix/$host/{include,lib}, based on the pre-sysroot convention; so if we want to use the sysroot for *everything*, including the system headers, then they end up in $CROSS_PREFIX/$CROSS_HOST/{include,lib} and need to be moved thereafter. Sorry, I was confused because my mingw64-zlib seemed to behave like the mingw64.org packages -- hence, not a mingw64.org-specific problem, but rather a cygport problem (e.g. what's the common link between these packages: they each are built by cygport, and inherit cross). However, zlib -- when building on mingw-ish using the autotool driven build process rather than scripts/makefile.mingw -- is an odd duck. I tried again with xz -- which is not an odd duck -- and it worked fine. CROSS_HOST=x86_64-w64-mingw32 ORIG_PN=xz inherit cross DESCRIPTION=liblzma for MinGW-w64 Win32 (64bit) toolchain HOMEPAGE=http://tukaani.org/xz/; SRC_URI=http://tukaani.org/xz/xz-${PV}.tar.xz; So, it turns out the ACTUAL problem (with zlib) is that I need to fix my buildsys patches to zlib, which enable using the autotool build system for cygming. Never mind. IOW this could be seen as an issue with the mingw-w64 sources, not cygport. OTOH, mingw-w64 is not unique; both newlib and avr-libc are coded to install into $prefix/$host/{include,lib}; glibc and mingw.org install correctly into sysroot OOTB. A possible solution is to reconsider to what degree we use the sysroot. No, sys-root is the best idea since sliced bread! Now that the libtool sysroot stuff has been merged upstream, I'm about to release an updated libtool for cygwin and mingw.org. This may be a bit premature (2.2.12 is due out RSN) but I've already delayed two or three weeks longer than I originally wanted. The installed-on-$build .la files will have the '=' markers, but updated libtool scripts will know how to ignore them if they are copied without change onto a native $host. OTOH, not even updated libltdl will know how to deal with those elements, yet, if the .la files are used to load modules. However, libtool (the script) now also supports taking .la files as arguments to mode=finish, and will fix that up for you. So, the procedure would be -- 1) copy your files to a staging area for packaging, so that they can be installed on $host 2) package them up, with a postinstall script or step that invokes libtool mode=finish list the .la files where the path to each .la file is the final on-$host path to the .la files in their installation location. This is not an uncommon procedure, at least on ELF platforms, I think. Even today, if you build a library with a non-standard $prefix and want to create an RPM or DEB, you need to invoke libtool mode=finish the dir where libraries are installed as part of your package's postinstall process. If you want to be strictly correct, that is. Now, this isn't something cygport needs to worry about -- unless cygport was *executed* itself on linux, using a linux-cygwin cross compiler, to generate packages to be installed on cygwin. I'm not real sure about the ${prefix%/...} manipulation, either, especially for cross. (The effect of this manipulation for a cross for $host=mingw is not apparent, since $prefix doesn't actually end in /usr in that case). But...the current code seems to be incorrect, IMO. The point is that (per FHS) if prefix=/usr, then sysconfdir=/etc (NOT /usr/etc) and localstatedir=/var (NOT /usr/var), However, if prefix != /usr (e.g. /mingw), then these should also go under the prefix (/mingw/etc and /mingw/var). The same goes for cyginstall. You're right, for native builds where prefix is actually /usr or /other. I was concerned about the 'cross' case, where prefix ends up being ${CROSS_SYSROOT}/usr or ${CROSS_SYSROOT}/mingw (that is, ends-with rather than starts-with /usr or /mingw) -- and I misread the substitution. (I should know by now to ALWAYS explicitly test what %, %%, #, and ## do in bash var substs, I can never remember exactly how they each behave...) Sorry for the false alarm. -- Chuck
Re: [ITP] mingw-w64 Second try
On 8/31/2010 11:20 PM, JonY wrote: On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it. Given the results of the thread re: Possible cygport bug with cross compiles (e.g. there is no bug), it looks like: 1) rebuild the -header package so that the includes end up in the correct location. The current cygport(5) for that package is fine (e.g. (a) the extra rule in src_install is needed, and proper, and (b) it does the right thing) 2) fix the setup.hints and you're GTG! -- Chuck
Re: [ITP] mingw-w64 Second try
On 9/1/2010 23:15, Charles Wilson wrote: On 8/31/2010 11:20 PM, JonY wrote: On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it. Given the results of the thread re: Possible cygport bug with cross compiles (e.g. there is no bug), it looks like: 1) rebuild the -header package so that the includes end up in the correct location. The current cygport(5) for that package is fine (e.g. (a) the extra rule in src_install is needed, and proper, and (b) it does the right thing) I am getting a permission denied error that I wasn't aware of before. I have fixed the mv command, and tested with cygport compile install list, cyport list does show the correct locations. Tarball reuploaded. 2) fix the setup.hints Does setup.hint itself (for mingw64-x86_64-gcc-core) need an external-source link to mingw64-x86_64-gcc?
Re: [ITP] mingw-w64 Second try
On 9/1/2010 11:44 AM, JonY wrote: On 9/1/2010 23:15, Charles Wilson wrote: On 8/31/2010 11:20 PM, JonY wrote: On 9/1/2010 10:28, Charles Wilson wrote: On 8/31/2010 8:52 PM, JonY wrote: Strange, I'll try a rebuild. The former should be the correct location. Errr...no. The *latter* is the correct location (at least, that's where the sysroot'ed compiler will look for them). the (buggy) cygport(1) puts them in usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/ but we really want them to be in usr/x86_64-w64-mingw32/sys-root/mingw/include/ which is what your cygport(5) does -- when you actually use it to rebuild. Right, the latter is correct. I'm misreading it. Given the results of the thread re: Possible cygport bug with cross compiles (e.g. there is no bug), it looks like: 1) rebuild the -header package so that the includes end up in the correct location. The current cygport(5) for that package is fine (e.g. (a) the extra rule in src_install is needed, and proper, and (b) it does the right thing) I am getting a permission denied error that I wasn't aware of before. I have fixed the mv command, and tested with cygport compile install list, cyport list does show the correct locations. Tarball reuploaded. 2) fix the setup.hints Does setup.hint itself (for mingw64-x86_64-gcc-core) need an external-source link to mingw64-x86_64-gcc? Well, you'd actually need two setup.hints: mingw64-x86_64-gcc/ mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2 (1) setup.hint mingw64-x86_64-gcc-core/ mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2 (2)setup.hint mingw64-x86_64-gcc-fortran/ mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2 setup.hint mingw64-x86_64-gcc-g++/ mingw64-x86_64-gcc-g++-4.5.1-1.tar.bz2 setup.hint mingw64-x86_64-gcc-ada/ mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2 setup.hint The one marked (1) would not need any requires: or external-source: marking. The one marked (2) would only need an external-source: marking. The others would all need both an external-source AND a requires: mingw64-x86_64-gcc-core marking. I think this also means you need to modify your cygport(5) from PKG_NAMES=${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc PKG_HINTS=setup ada g++ gfortran objc to PKG_NAMES=${PN} ${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc PKG_HINTS=setup core ada g++ gfortran objc where the new core.hint file has the contents of the existing setup.hint file (as updated above), and the new setup.hint file just says category: Devel sdesc: GCC for MinGW-w64 Win64 toolchain (source) I *think* this means that you'll then get an EMPTY mingw64-x86_64-gcc-4.5.1-1.tar.bz2 package, but you won't want to include that in the upload set. -- Chuck