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] |
On 7/17/2010 4:26 PM, Charles Wilson wrote: > I'll post more after I use the new tools to build the various non-core > packages that exercise the cross.cygclass, such as linux-ncurses, > mingw-bzip2, etc. I'll address issues with libtool/pkgconfig at that > time, as well (short version: our version of pkgconfig claims to support > sysroot via $PKG_CONFIG_SYSROOT_DIR, but newer versions have supposedly > improved that support. Also, there was one patch, and another promised, > on libtool-patches addressing just this issue, in the last week). OK, so the libtool stuff is still percolating. Paolo just posted his patch series earlier today, so I haven't had a chance to test it out yet. However, it APPEARS after a cursory glance to work like this: 1) you configure stuff with --prefix=${CROSS_SYSROOT}${prefix} 2) libtool, when generating the .la file, observes all of the various -L and -R options. It recognizes when each argument starts_with $sysroot, and does the following: a) replaces the original argument to -L and -R with the value sans $sysroot. b) stores the value of the sysroot as a separate variable in the .la file. 3) Then, when *using* the .la file, you pass a new '-sysroot' option to libtool. That tells libtool to reconstruct the original $sysroot$prefix path. OTOH, if you *don't* pass -sysroot, then the normal operation ensues -- and since $sysroot has been stripped from all -L and -R arguments, operation is "native". I've seen absolute paths to other objects buried in .la files (e.g. without -L options; e.g. deplibs=/usr/long/path/to/buried/prefix/lib/libfoo.la. I don't know how Paolo's patch deals with that, if $sysroot=/usr/long/path/to/buried But...as I read the proposal, you *would* want to configure with --prefix=$sysroot$prefix. I think. Now, maybe there is something I'm not seeing, but it sure seems to me that the better solution is to configure with --prefix=$prefix, and then add support for $sysroot on the back end, instead of configuring with $sysroot$prefix and trying to strip out references to $sysroot on the front end. The reason I think this is, I'm concerned about *hardcoding* the $sysroot$prefix values into the compiled binaries! (e.g. 'strings foo.exe | grep $sysroot' might return non-empty, and that would be bad, when foo.exe is deployed on the $host system in $prefix. But...this is all just my guess based on inspection of the code; I haven't been able to test it yet. Ditto WRT pkg-config. I plan to simply update our pkg-config to the latest upstream, and see if that helps wrt $PKG_CONFIG_SYSROOT_DIR. One thing I thought of; if you want to run foo-config scripts from /usr/i686-pc-mingw32/sys-root/mingw/bin during configure, then you pretty much have to set $PATH so that $sysroot$prefix/bin precedes your own /usr/bin -- otherwise, you'd get /usr/bin/foo-config. But...what if you're creating a REAL, full sysroot. Like, with coreutils and everything, over there in $sysroot$prefix/bin. Do you REALLY want the cross-$host version of 'uname' to precede your own? Probably not. I'm not sure what the "right" answer here is, except maybe for packagers to arrange so that munged copies of any foo-config scripts are placed in /usr/$host/bin (or, if that scares you, then /usr/$host/scripts/). That way, the foo-configs in $sysroot$prefix/bin are usable only once deployed onto the cross $host under $prefix, but the ones in /usr/$host/scripts are usuable on the $build system. I think that's probably easier than patching every package that ships a foo-config, so that foo-config accepts a -sysroot option. But...a patch adding a -sysroot option to a foo-config would probably be accepted by the upstream maintainers of foo. ======================== Now, as far as using the cross.cygclass to build non-core stuff. Using my original mingw-{zlib,bzip2,xz,gpg-error,gcrypt} cygports and Yaakov's versions, I've created local versions of all those packages using the new tools and the i686-pc-mingw32 compiler. It all seemed to go pretty smoothly; my cygports are still uglier than Yaakov's, but that's partly because I was trying to maintain strict one-for-one compatibility with the old versions (mgwbz2_1.dll names, and all). Later on, we might think about breaking backwards compat on those packages (esp. the DLLs, since nobody uses them yet) and make "ours" more normal, and the cygports more clean. But not yet. Of course, I also brought over all my .hints and .READMEs; these are "real" packages, not proof-of-concepts (even if I may have to rebuild them all again anyway, once the official mingw.org-based cross compiler is released). Here's the key bit: using these packages, I was able to build a working setup.exe using both i686-pc-mingw32-g++, and g++-3 -mno-cygwin (without resorting to setup-no-autoload.patch). Here's how I did it: 1) mingw-gcc compiled with: CYGCONF_ARGS=" --disable-multilib --disable-sjlj-exceptions --enable-lto --enable-languages=c,c++,fortran,objc,obj-c++ --enable-libgomp --enable-version-specific-runtime-libs --disable-win32-registry --with-dwarf2 --localedir=/usr/${TOOLCHAIN_TARGET}/share/locale " I had a mingw-pthread available so --enable-libgomp DID have an effect. However, as noted previously, --localedir did NOT. I also recompiled mingw-runtime (new-style), mingw-w32api, and mingw-pthreads using the new gcc. However, I didn't take any care to ensure that -mms-bitfields was used. 2) For ALL of the mingw-{zlib,bzip2,xz,gpg-error,gcrypt} packages, I made sure that each was compiled with -mms-bitfields. All of the *-mingw32-* packages shipped by mingw.org are built that way, even though it is not the default for the compiler. I really think it ought to BE the default for *mingw32*, but that train has long left the station. 3) I also *linked* all of the DLLs and EXEs in these packages using -shared-libgcc. This has no effect on the setup.exe test, but I mention it for thoroughness. 4) I linked setup.exe with -static-libgcc, naturally. 5) I, too, had to manually modify /usr/i686-pc-mingw32/sys-root/mingw/lib/libgcrypt.la in order to link setup.exe, but that is a libtool-doesn't-understand-sysroot-yet problem: # Libraries that this one depends upon. -dependency_libs=' -L/mingw/lib /mingw/lib/libgpg-error.la' +dependency_libs=' -L/mingw/lib /usr/i686-pc-mingw32/sys-root/mingw/lib/libgpg-error.la' 6) I used Yaakov's setup-gcc45.patch to start with, but in order to ensure that setup's .o objects were all compiled with -mms-bitfields, I had to extend his changes (see attached; apply after setup-gcc45.patch). Now, with all of those changes, setup.exe worked. However, if I compiled setup.exe using i686-pc-mingw32-gcc WITHOUT -mms-bitfields, then I got an 0xc0000005 error. The other interesting bit was, using these mingw-{...} packages, and a little bit of magic, I was able to compile a working setup.exe using gcc-3 -mno-cygwin. I'll describe how that worked in another message, as it has implications for how we manage the rollout of the mingw.org-based cross compiler and the (semi-)retirement of gcc3. I've attached the cygport and patches for these five packages here. -- Chuck
--- yaakov-doconfigure 2010-07-22 22:15:40.183524400 -0400 +++ chuck-doconfigure 2010-07-22 22:14:51.064724400 -0400 @@ -14,14 +14,19 @@ cmd=$cmd' -C --disable-shared --enable-maintainer-mode' cmd=$cmd' --host=i686-pc-mingw32 --build=i686-pc-cygwin' cmd=$cmd' CC="i686-pc-mingw32-gcc" CXX="i686-pc-mingw32-g++"' +cflags="-mms-bitfields" +cxxflags="-mms-bitfields" for i in "$@"; do case $i in maint) cmd=$cmd' CPPFLAGS=-DMAINTAINER_FEATURES' ;; - debug) cmd=$cmd' CFLAGS="-g -O0" CXXFLAGS="-g -O0"' ;; + debug) cflags=$cflags' -g -O0' + cxxflags=$cxxflags' -g -O0' ;; *) echo "Unexpected argument: '$i'" >&2; exit 1 ;; esac done +cmd=$cmd' CFLAGS="${cflags}" CXXFLAGS="${cxxflags}"' + echo -e "\033[32;1mRunning $DIR/configure\033[0m" eval "$cmd"
Attachment:
chuck-mingw-cygport-examples.lzma
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |