Re: cygport cross-compiling beta1
On Sat, 2010-07-24 at 10:34 -0400, Charles Wilson wrote: Same problem. Using Yaakov's latest pre-built linux cross compiler, and the latest linux-glibc src package, I attempted to rebuild. First I had the same problem where -jN was too aggressive on my quad core box, so I backed that down to -j1. But then I had a link error at the very end of the build: Do you have the linux-i686-kernel-headers installed as well? You do need those for both building and using glibc. Otherwise, I'm baffled; I didn't do anything to build glibc beyond what is in my .cygport. Yaakov
[PATCH] Rename setup.exe's Partial view to Changing
Hi, I hereby propose to rename setup.exe's Partial view to Changing, because Partial only tells the user that it's going to show some subset of packages, whereas Changing should make it more obvious that it's showing the packages that are, well, changing. Hopefully this will make it a bit more discoverable, although of course it might cause some confusion for users who already know about Partial. Attached are small patches to setup.exe as well as the manual and FAQ that implement this change. setup/ChangeLog: * PickView.cc (PickView::views::caption): Rename Partial view to Changing. * res.rc (IDS_VIEWBUTTON_TOOLTIP): Ditto. cygwin/winsup/doc/ChangeLog: * setup-net.sgml, faq-setup.xml: Rename setup.exe's Partial view to Changing. Andy changing-view-doc.patch Description: Binary data changing-view-setup.patch Description: Binary data
Re: [PATCH] Rename setup.exe's Partial view to Changing
On Sun, Jul 25, 2010 at 05:43:35PM +0100, Andy Koppe wrote: Hi, I hereby propose to rename setup.exe's Partial view to Changing, because Partial only tells the user that it's going to show some subset of packages, whereas Changing should make it more obvious that it's showing the packages that are, well, changing. Hopefully this will make it a bit more discoverable, although of course it might cause some confusion for users who already know about Partial. Attached are small patches to setup.exe as well as the manual and FAQ that implement this change. setup/ChangeLog: * PickView.cc (PickView::views::caption): Rename Partial view to Changing. * res.rc (IDS_VIEWBUTTON_TOOLTIP): Ditto. cygwin/winsup/doc/ChangeLog: * setup-net.sgml, faq-setup.xml: Rename setup.exe's Partial view to Changing. I agree that Partial needs renaming but I don't think Changing is clearer. How about Updating? cgf
Re: cygport cross-compiling beta1
On 7/25/2010 2:00 AM, Yaakov (Cygwin/X) wrote: On Sat, 2010-07-24 at 10:34 -0400, Charles Wilson wrote: Same problem. Using Yaakov's latest pre-built linux cross compiler, and the latest linux-glibc src package, I attempted to rebuild. First I had the same problem where -jN was too aggressive on my quad core box, so I backed that down to -j1. But then I had a link error at the very end of the build: Do you have the linux-i686-kernel-headers installed as well? You do need those for both building and using glibc. Otherwise, I'm baffled; I didn't do anything to build glibc beyond what is in my .cygport. I do. I'm stumped. I think the only thing left that might give some clues is a line-by-line comparison of the config.log and build log output, which is why I uploaded them. -- Chuck
Re: cygport cross-compiling beta1
On 7/22/2010 8:47 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote: Why shouldn't cygport allow that? Thinking about this further, I think the problem is that we're talking about two entirely different use cases: 1) cross-compiling a package to install into the sysroot, to be used solely on Cygwin for cross-compile other software, which would follow Cygwin packaging guidelines and use the system-default prefix; 2) cross-compiling software for use on another system (along the lines of canadian-cross.cygclass), which would follow the *host*'s packaging guidelines, or that of the user (at least wrt prefix). These are two completely different scenarios and in order to cover both of them w/o confusion, I think we should handle them separately, particularly if (as I suspect) we are forced to prepend $CROSS_SYSROOT to $prefix for case (1). My early tests with Paolo's libtool patches look promising. You configure with --prefix=$prefix (not sysroot), and libtool takes care of the rest. When libtool detects a cross build sysroot situation, you basically end up with a magic pattern in the deplibs variable of the .la file: (lib2.la depends on lib1.la): dependency_libs=' =/mingw/lib/lib1.la =/mingw/lib/lib1.la' libdir='/mingw/lib' (Also, -L and -R entities are similarly munged, to include the '=' marker for sysroot builds) When linking, libtool doesn't warn about relocations because it knows about sysroots. It all seems to work on the $build system as expected. My concern -- which I haven't tested -- is three-fold: 1) what happens when an old libtool sees that '=/path pattern? Do all clients need to have an updated libtool, in order to be built against the libs even on the $build machine? 2) Can you deploy these .la's on the $host machine for futher, native development? How does libtool deal with the magic '=' symbol, when you DON'T have a sysroot are are building a client using a native compiler, against a lib that was built elsewhere using a cross compiler? 3) So, you build a product that uses libtool modules for dynamic loading, and it needs the .la files so that libltdl can do its thing. Will module .la's have this '=' symbol in them? If so, will that confuse libltdl? More testing to do... So how about this: leave cross.cygclass to handle case (1), since that was what it was originally designed for, and make a new cygclass for case (2), sort of like a generalized canadian-cross.cygclass (which would be removed). The API would look something like: NAMESPACE_HOST=i686-pc-linux-gnu NAMESPACE_PREFIX=/usr/local # defaults to /mingw or /usr inherit namespace [...] The only question is what to use for namespace? DEPLOY ? DIST? -- Chuck
Re: cygport cross-compiling beta1
On 7/25/2010 5:01 AM, Yaakov (Cygwin/X) wrote: On Sat, 2010-07-24 at 00:26 -0400, Charles Wilson wrote: What does gentoo do with cross compilers and sysroots? I know ebuild/emerge supports them; do they treat them strictly as support for cross compiles, or as installable images on the intended $host? I suspect the latter... Not AFAICS: http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1chap=3#doc_chap2 That's sad. It's also limiting. It means that you *can't* -- using gentoo's crossdev framework -- build a -dev package for the $host, that someone ELSE could use for native development ON $host. I fear this would also be a limitation of any cross.cygclass | deploy.cygclass bifurcation we cooked up. OTOH, cygport is NOT a package manager, it is a build tool which creates package tarballs, which are easily unpacked on other systems. So I wouldn't mind making a separate cygclass for that purpose, which would also allow for $prefix customization. In fact, it's basically ready, but I'm not sure what to call it[1]. [1] http://cygwin.com/ml/cygwin-apps/2010-07/msg00174.html But, could I use $WHATEVER.cygclass to build libfoo for the $host libbar for the $host -- when libbar depends on libfoo? I suspect the only way to make this work would be to have TWO $host copies of libfoo: The deploy-on-$host version, which the end user would need. But also the local $build.cross version, in order to link libbar-for-deploy-on-$host. But then you get into issues with relinking and embedded rpaths (at least for ELF; not so much for PE/COFF). It really seems like TRTTD is to make the two trees one, and *fix* the issues with libtool, pkgconfig, and foo-config. OTOH, we're just a tiny little FOSS project; if the Big Boys haven't solved this by now, and even gentoo, fedora, and debian have all given up on the project...would we be tilting at windmills to try to solve it with our limited resources here? We could go that route as well; it just strikes me as a shame to give up since win32 is /right there/ underneath cygwin all along... OTOH, even on fedora-x86, it'd be nice to be able to map $sysroot$prefix to some specific wine path (identity mount inside wine, as $prefix?), and run the binaries in place. That would let you, in some cases, run package test suites and the like. For testing MinGW binaries, because they see only Windows paths, *either way* you have a problem running in the sysroot IF $prefix et al are used in the code at runtime (/mingw != C:\mingw) or if the tests pass Cygwin-native paths to the executable. Yes, I know. But...many times testsuites use only relative paths, which will work fine (as long as you don't use symlinks in your source tree for some reason). It won't ALWAYS work, but at least we wouldn't be deliberately creating MORE breakages, through our choice of cross compile strategies. If not, either because there is no runtime data or modules to find, or because it is coded to be relocatable (at least on Windows, which is not uncommon), then you should still be able to test-run cross-built programs using sysroot libraries by appending $sysroot$prefix/bin to path. That might very well be why Fedora moves libgcc and friends into the sysroot. Yes, probably so. AFAICS the only thing you lose by configuring --prefix=$sysroot$prefix is transferability between the sysroot and the host, IOW: Which would seem to me to be a pretty big deal. I mean, what's the point of cross compiling something if you can never use it on the $host? Sure, you could compile all the prereqs for, say, GIMP, to create a suitable compilation environment/sysroot on $build, so that you CAN then finally go ahead an compile GIMP itself for $host. But I'd assume at that point you'd want to copy GIMP over TO the $host and use it. And that means you need -- what? a SECOND version of all of those same prereqs, only this time compiled in a non-sysroot manner, so that the runtime deps of GIMP can also be deployed over on $host? That seems...excessive. (And I'm assuming that all the deps of GIMP are simple; they don't actually have interacting dependencies with each other. That makes things even MORE complicated, and unfortunately my assumption is counterfactual.) 1) sysroot-configured libraries would not run on the host if runtime data/module paths are hard-coded; Well, at least .la files can be postprocessed for deployment. No such luck for compiled-in paths. There's a strong feeling among some win32 folks that any properly ported app will be $prefix-independent; that it will always deduce its own location and use relative paths exclusively. Nice idea, but the FOSS universe isn't there yet. 2) sysroot-configured ELF libraries would have an extra RPATH pointing to the sysroot, which IIUC should be harmless (could this be mitigated by patching libtool to not use $hardcode_libdir_flag_spec when $libdir is in $sys_lib_search_path_spec?); The is
Re: [PATCH] Rename setup.exe's Partial view to Changing
On 26 July 2010 00:17, Christopher Faylor wrote: On Sun, Jul 25, 2010 at 05:43:35PM +0100, Andy Koppe wrote: I hereby propose to rename setup.exe's Partial view to Changing, because Partial only tells the user that it's going to show some subset of packages, whereas Changing should make it more obvious that it's showing the packages that are, well, changing. Hopefully this will make it a bit more discoverable, although of course it might cause some confusion for users who already know about Partial. I agree that Partial needs renaming but I don't think Changing is clearer. How about Updating? I see where you're coming from, because if the user changes nothing else, only packages that are being updated will appear on that view. Yet it does include any added, removed, or downgraded packages too, so I'm not convinced. Changes? Modified? Andy
src/winsup/mingw ChangeLog include/float.h
CVSROOT:/cvs/src Module name:src Changes by: keithmarsh...@sourceware.org2010-07-25 20:20:46 Modified files: winsup/mingw : ChangeLog winsup/mingw/include: float.h Log message: Accept that mingwrt headers are not guaranteed to precede GCC's in the system include search path; (issue reported by Mark Brand). Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.462r2=1.463 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/float.h.diff?cvsroot=srcr1=1.7r2=1.8
Re: Request for feature: more flexible setup routine
On 25 July 2010 03:54, Christopher Faylor wrote: On Sat, Jul 24, 2010 at 07:10:08PM -0500, Marshall Abrams wrote: One of the beautiful things about Cygwin's setup.exe is that when--perhaps in the middle of trying to get something done before a deadline--I realize that a Cygwin package I didn't think I'd need would help. If it hasn't been *too* long since I last installed, I go and mark the package to install, carefully make sure that I mark all other new packages as keep, and hit next. *Although* you should be able to set everything to keep and just update the one package that you want ... by simply clicking on the Keep button near the top of the package selection screen. This makes me wonder whether Keep shouldn't be the default, on the principle that programs shouldn't do anything unless the user asks for it. Also, if you're trying to stick with a proven install, forgetting to click Keep is much worse then if you're trying to stay up-to-date yet you forget to change from Keep to Curr. In the first case, you need to restore a backup assuming you have one, whereas in the second you just need to run setup again. Yet of course the argument for having Curr as the default is that we want to encourage users to update to the latest versions as we can't support a myriad of different combinations of old package versions. Hmm. How about leaving the default as is but remembering the state of Keep/Curr/Prev/Exp across setup.exe invocations? Would a patch for that be welcome? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin command line takes a long time to start
On Fri, Jul 23, 2010 at 3:53 AM, David Antliff wrote: How would one go about debugging the bash or mintty startup before .bash_profile is read? Duplicate your shortcut which launches bash and add -x to the bash options (which should include -l a.k.a. --login) e.g. C:\cygwin17\bin\mintty.exe -h error /usr/bin/bash --login -x If using cygwin.bat, add -x after bash --login -i -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin command line takes a long time to start
On Mon, Jul 26, 2010 at 08:12, Csaba Raduly wrote: On Fri, Jul 23, 2010 at 3:53 AM, David Antliff wrote: How would one go about debugging the bash or mintty startup before .bash_profile is read? Duplicate your shortcut which launches bash and add -x to the bash options (which should include -l a.k.a. --login) Thanks everyone - using these tips I was able to determine that bash_completion was actually running twice - once by /etc/profile.d/bash_completion.sh, and again by my own .bash_profile, which was modifying the path prior to invoking it so that apps in my ~/bin were picked up. I don't actually have anything useful in there any more so it's really just a bunch of old stuff I brought over from my Linux config. I've tidied it up now. I now get the bash prompt after about 5 seconds, rather than 10. Disabling bash_completion completely gives me a prompt in less than 1 second, but I do quite like bash_completion so I'll live with that. -- David. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
