Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-1913543 ] Incorrect packaging of several MSYS-1.0.11 components
|
From: SourceForge.net <no...@so...> - 2008-05-01 01:03:08
|
Bugs item #1913543, was opened at 2008-03-13 10:17 Message generated for change (Comment added) made by cwilso11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1913543&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MSYS Group: None Status: Open Resolution: None Priority: 9 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Charles Wilson (cwilso11) Summary: Incorrect packaging of several MSYS-1.0.11 components Initial Comment: Earnie has previously noted this informally, on the mailing list; several of the component packages have been assembled with the relative path name in the tarball set as `usr/...' or `/usr/local/...'. This breaks the MSYS installation, if the user installs these directly into the MSYS root, using any archiving tool other than MSYS' own tar command. Since any integrated installer package will have to run as a native Woe32 app, I now believe correction of these package structures must be considered a priority; all need to have the `usr/' prefix removed from the path name stored in their respective tarballs. The offending packages I've identified are, in the `MSYS Base System' set: csmake-3.81-MSYS-1.0.11-1.tar.bz2 make-3.81-MSYS-1.0.11-1.tar.bz2 texinfo-4.11-MSYS-1.0.11.tar.bz2 in the `MSYS Supplementary Tools' set: autoconf-4-1-bin.tar.bz2 autoconf2.1-2.13-3-bin.tar.bz2 autoconf2.5-2.61-1-bin.tar.bz2 autogen-5.9.2-MSYS-1.0.11.tar.bz2 automake-3-1-bin.tar.bz2 automake1.10-1.10-1-bin.tar.bz2 automake1.9-1.9.6-2-bin.tar.bz2 bison-2.3-MSYS-1.0.11.tar.bz2 crypt-1.1-1-MSYS-1.0.11.tar.bz2 cvs-1.11.22-MSYS-1.0.11.tar.bz2 flex-2.5.33-MSYS-1.0.11.tar.bz2 gdbm-1.8.3-MSYS-1.0.11.tar.bz2 gettext-0.16.1-1-bin.tar.bz2 gettext-0.16.1-1-dll.tar.bz2 gettext-0.16.1-MSYS-1.0.11.tar.bz2 gettext-devel-0.16.1-MSYS-1.0.11.tar.bz2 gmp-4.2.1-MSYS-1.0.11.tar.bz2 guile-1.8.2-MSYS-1.0.11.tar.bz2 inetutils-1.3.2-36-MSYS-1.0.11.tar.bz2 libiconv-1.11-1-bin.tar.bz2 libiconv-1.11-1-dll.tar.bz2 libiconv-1.11-MSYS-1.0.11.tar.bz2 libtool1.5-1.5.25a-1-bin.tar.bz2 libtool1.5-1.5.25a-1-dll.tar.bz2 lndir-6.8.1.0-MSYS-1.0.11.tar.bz2 lpr-1.0.1-MSYS.tar.gz minires-1.01-1-MSYS-1.0.11.tar.bz2 openssh-4.6p1-MSYS-1.0.11.tar.bz2 openssl-0.9.8e-3-MSYS-1.0.11.tar.bz2 perl-5.6.1-MSYS-1.0.11.tar.bz2 perl-man-5.6.1-MSYS-1.0.11.tar.bz2 regex-0.12-MSYS-1.0.11.tar.bz2 vim-7.1-MSYS-1.0.11.tar.bz2 zlib-1.2.3-MSYS-1.0.11.tar.bz2 and in the `MSYS System Builder' set: autoconf-2.61-MSYS-1.0.11.tar.bz2 automake-1.10-MSYS-1.0.11.tar.bz2 libtool1.5-1.5.25a-20070701-MSYS-1.0.11.tar.bz2 termcap-20050421-MSYS-1.0.11.tar.bz2 IIRC, the majority of these are Chuck's contributions, (thanks Chuck), hence the assignment for this bug. I do note the lpr package in there, which was mine, so I'll certainly fix that myself; I'll also help with the others, if you let me know which you'd like me to pick up. Regards, Keith. ---------------------------------------------------------------------- >Comment By: Charles Wilson (cwilso11) Date: 2008-04-30 21:03 Message: Logged In: YES user_id=1384893 Originator: NO > Cesar has alluded to similar problems, where the makefiles > rely on case sensitivity in the pseudo-targets, e.g. install > vs. INSTALL. I definitely consider this to be a makefile bug. > It is inexcusable in the autotools, for it is so easily > avoided, and it is precisely this sort of portability issue > that these tools are supposed to address. Well, in your particular example, it's hard to see what the "right" fix is. 'make install' is just as deeply entrenched in everyone's finger-memory as is the GNU custom -- enshrined in the GNU Coding Standards, no less -- of including a file named 'INSTALL' describing how to install the package. On a case-insensitive system, how can they NOT clash? One has to be renamed...good luck with that. > Thus, when MinGW GCC stats /usr/local, Why does it do this? If you do not have -I/usr/local, why would gcc ever look there? > it finds D:/usr/local, which MSYS also knows as /usr/local, and > the path is added to GCC's default search hierarchy. Again, why? I thought mingw-gcc explicitly did NOT have a list of "probably system dirs" that it would look for automatically, other than ${where-am-i}/<some-rel-path>/lib/gcc-lib/${gcc-ver}/include and ${where-am-i}/../include. > I think this is probably the strategy we should adopt for the > native builds of development library kits we distribute. I disagree, UNLESS we adopt a package installation manager that can handle the contents of these augmented C:\mingw-${myver} directories. That is, currently the contents of C:\mingw -- as installed by the official installer -- consist only of the compiler(s), the debugger, binutils, and the bare minimum of libraries and header files necessary to compile win32 applications (w32api and mingw-runtime). If that set is /officially/ augmented to include a larger set of packages, we need a better way for our users to manage that installation. The main reason for separating the native versions of the autotools into /usr/local (as opposed to /mingw, where a mingwPORT would put them by default), was to avoid the problems for users maintaining /mingw with so many dissimilar and relatively unrelated packages, without any effective tools to do so. > Of course, if we adopt this approach, it does rather beg the > question, are these native kits MSYS tools, or are they MinGW > add ons? IOW, should the native builds of libiconv, gettext, > etc. be pulled from the MSYS Supplementary Tools, and offered > as MinGW User Contributed packages instead? Well, they /are/ tools used to build, configure, and maintain other *mingw* packages. But then, the same is true of all MSYS packages -- their only purpose in life is to help users maintain and build *mingw* products (with the exception of those packages needed for developing the MSYS tools themselves). So might as well move /everything/ in MSYS Supplemental into Mingw User Contrib -- but then what have you accomplished? OTOH, none of them are useful at all, without MSYS: binary tools because they link against the MSYS dll, script tools because they require an interpreter that is linked against the MSYS dll (no, I don't even want to think about trying to get autoconf to work reliably with a purely win32 perl like ActiveState) -- and because they call a huge number of dinky little system utilities in the True Unix Way, each of which are linked to the MSYS dll. So, script or binary -- they are /all/ MSYS tools. It's not like there are "two groups" -- any argument you make about perl.exe, on way or the other, I can make an identical one about autoconf-2.61. > Then, what do we do with those extras such as autoconf, automake, > etc., which are command line tools using Bourne shell scripting, or > perl, or m4, which are therefore MSYS dependent? Yes. The Supplemental Tools are all of a piece -- whether you call 'em "MSYS" or "MinGW". > Come to think of > it, why do we even need distinct versions of autoconf or automake > for native or MSYS special use? Because all of the autotools share a common m4 archive, and all add-on tools that provide .m4 files will add them to that archive, in ${prefix}/share/aclocal*/. If you mix-n-match, you are in a world of hurt. For instance, suppose for instance that we discover, due to some unforeseen issue with MSYS-1.0.11 and/or gcc-2.95.3, that we are stuck with gettext-0.16.1 well past the release of gettext-0.19. gettext provides a lot of m4 files, and they could change radically between releases. We need a place to install the *mingw* version of gettext's m4 files so that it/they can be used when autotooling (gettextizing) a mingw-destined package. But if we clobber the (common between MSYS and "mingw") m4 files... Furthermore, gettext, in addition to wearing an autotool hat, also provides a runtime library (which depends on libiconv, so that's included in the "basic set of stuff for autotool use" as well). Ditto libtool. Obviously you need different versions of this library for native and MSYS use. Unless you want to make things VERY difficult -- with renaming the import libraries and playing games with the MSYS-versions of the .m4 files so that LTLIBINTL gets the "correct" import library name...you really need to have the MSYS gettext (libintl*) and MSYS libiconv installed into a different prefix -- or at least, with a different includedir and libdir (see m4 munging, above) -- than the mingw versions. Furthermore, the gettext and libiconv upstream sources are, since 0.15, now configured to build shared on "Woe32" using a rather unique scheme devised by Bruno Haible -- but that scheme requires compiler support not available in gcc-2.95.3. This scheme also makes changes in the *static libraries* -- it's not just that the dll is absent. So the msys versions of gettext and libiconv have to turn that stuff off. As if having the libraries themselves dependent on different runtimes wasn't enough of a reason to have two versions of gettext and libiconv! But now, we've identified a need for custom --datarootdir (to keep the msys m4 archive separate from the mingw m4 archive, to prevent possible version incompatibilities), a custom --includedir and --libdir (to keep the headers distinct -- again, for versioning concerns, and to keep the static libraries distinct), for the libtool, gettext and libiconv 'autotools'. Plus, we need a custom --datarootdir for the automake/aclocal autotools so that they will use the appropriate .m4 versions for the proper [msys|mingw]-associated gettext, libiconv, and libtool packages. And did I mention a custom --bindir, so that the different version of the tools themselves, don't clobber each other? At that point, you're really better off using a different --prefix entirely for the two sets of tools. The msys-associated one should just go into /usr aka /, and, of course, the mingw-associated one is a whole 'nother question. But returning to the original question: why do you need two complete sets anyway? (1) gettext/libiconv/libtool provide runtime components that must be distinct (2) all autotools will use /the/ common .m4 archive in ${prefix}/share/aclocal*/, and all tools which provide .m4 files will install them into the same directory -- including gettext/libiconv/libtool, above. (3) Therefore, you need one aclocal/automake that uses ${msysprefix}/share/aclocal/, and a different one that uses ${mingwprefix}/share/aclocal. (4) at that point, since you're already providing msys-specific versions of four out of five autotools, why not add autoconf to the mix, for completeness -- and to keep the "autotool kits" for the two environments completely disassociated? And this, boys and girls, it what we call "burying the lead" in the newspaper bidness: Finally, the autoconf and automake source code has been *patched* to operate for the msys $target. Notably, the upstream config.guess and config.sub files do not have support for msys. This was a deliberate decision by Earnie that dates back to at least 2003: http://www.cmake.org/pipermail/cmake/2003-February/003312.html "I never meant MSYS to be an official host, target or build system so I've never added it to the config.guess and config.sub files officially, " > (I don't know enough about the > other tools Chuck mentions, to know if the same may be asked of them). You can ask...but it's all one big related question, as you can see above. Fortunately, the autotools really consist of just the four packages: gettext/libtool/automake/autoconf, and one dependent library, libiconv. So it's not likely to get much more complicated. > [stuff about msys-gcc, build platforms, lifetime issues, and OS version longevity] Well, I think the best bet -- even if not a quick solution -- is (1) get gcc-4.3.x (or 4.4.x if it takes that long) working *well* for mingw *and cygwin*. (2) clone the cygwin $target bits and modify to create an msys $target -- probably first as a cross compiler from a *nix or cygwin $build=$host, as a private patch [*] (3) then try to get it self-hosting under MSYS-1.0.19. [*] private in that it would not be submitted for official inclusion upstream, because to do THAT, (a) you'd need to patch the autotools appropriately, (b) push those changes into gcc, (c) and you'd need a much bigger development community [**] than we have or even want, in order to justify to the gcc steering committee that the msys target should be added at all. [**] a community focused on building apps *for the msys environment*. Right now, that community is about 5 or 10, tops. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-04-30 15:36 Message: Logged In: YES user_id=823908 Originator: YES > (1) the automake build goes into an infloop during 'make install' > if the non-case-sensitive make is used. I had to use csmake. This > is probably a bug in automake's own makefiles, but I didn't have > time to track it down. Cesar has alluded to similar problems, where the makefiles rely on case sensitivity in the pseudo-targets, e.g. install vs. INSTALL. I definitely consider this to be a makefile bug. It is inexcusable in the autotools, for it is so easily avoided, and it is precisely this sort of portability issue that these tools are supposed to address. > (2) the msys gcc (gcc-2.95.3) has /usr/local/include and > /usr/local/lib in its specs. This means that /usr/local/\ > include/iconv.h was used when compiling gettext, and apps > were linked against /usr/local/lib/libiconv.dll.a (or they > were, until I took drastic steps). This is bad, because > I'm trying to build msys tools but was linking against > native libraries. Curiously, I discovered only last week that my MinGW GCC-3.4.5 *is* searching in /usr/local/include and /usr/local/lib *by* *default*, in spite of our habitual declaration that this doesn't happen! I admit that I was surprised by this discovery, since I hadn't *deliberately* done anything to achieve such behaviour; however, I *had* set things up to let me share a common /usr/local tree among multiple MSYS installations, in a manner which coincidentally causes the effect. On reflection, it's obvious why it works this way, given my setup:-- D: +--usr | +--local | | +--<my locally installed stuff here> | | | +--mingw-3.4.5 | | +--<normal MinGW installation here> | | | +--msys-1.0.11 | | +--<MSYS-1.0.11 installed here> with my CWD nearly always being somewhere on drive D:, (usually within D:/usr/msys-1.0.11), and my /etc/fstab including the two entries:-- D:/usr/mingw-3.4.5 /mingw D:/usr/local /usr/local Thus, when MinGW GCC stats /usr/local, it finds D:/usr/local, which MSYS also knows as /usr/local, and the path is added to GCC's default search hierarchy. However, while the above may be interesting, it isn't something I've ever relied on to let GCC find my libraries and headers; my normal practice is to simply install all libraries and headers I will use routinely with MinGW into the /mingw prefix, whether that is the D:/usr/mingw-3.4.5 tree on my Win2K box, or my $HOME/mingw tree, where I keep the cross-compiler tool chain on the GNU/Linux box. That way, the particular versions of the libraries for each instance of GCC are appropriately located, using the built in default search path, and the correct version is used in each case. I think this is probably the strategy we should adopt for the native builds of development library kits we distribute. Of course, if we adopt this approach, it does rather beg the question, are these native kits MSYS tools, or are they MinGW add ons? IOW, should the native builds of libiconv, gettext, etc. be pulled from the MSYS Supplementary Tools, and offered as MinGW User Contributed packages instead? Then, what do we do with those extras such as autoconf, automake, etc., which are command line tools using Bourne shell scripting, or perl, or m4, which are therefore MSYS dependent? Come to think of it, why do we even need distinct versions of autoconf or automake for native or MSYS special use? (I don't know enough about the other tools Chuck mentions, to know if the same may be asked of them). > Finally, there is the issue of the msys-gcc itself. Recently, > we had a new release of gcc-3.4.5 specifically to deal with > vista problems. Do we need to backport whatever that fix was, > to gcc-2.95.3? I don't know. There's always the option of keeping a box with Win2K or WinXP alive, to support this type of development -- our company will be keeping a large number of Win2K workstations in service, with no OS updates whatsoever, for at least the next 20 years, simply because our plant automation system has that anticipated life cycle, and is certified for Win2K exclusively. > Is anybody willing to take on the pain of creating an > msys-gcc-3.4.5 package (or msys-gcc-favorite-newer-version)? I really do hope that one day someone will tackle that. I'd like to see it built in a more conventional cross-compiler format, so that it can be built more readily for use on other hosts, rather than requiring the present specialised MSYS set up; if I can build it so I can use it as:-- $ ./configure --build=linux --host=msys ... while others may do:-- $ ./configure --build=mingw32 --host=msys ... then I would be happy to participate in MSYS development myself, in a more active capacity. > Once XP disappears from common use, are we going to be stuck > without a way to (re)build msys tools? Having the tools built in a more conventional cross-compiler format will, IMO, help to guard against such an eventuality, since it will reduce dependency on a specific build environment. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-04-30 12:04 Message: Logged In: YES user_id=823908 Originator: YES I've now repackaged and uploaded the `lpr' scripts, with the new name of `lpr-1.0.1-1-MSYS-src.tar.gz', and I've deleted the original package from the FRS view. I've also amended the included README file, to reflect the differences in installation paths for MSYS and Cygwin -- (I originally cobbled this package together for use with Cygwin). I'll address Chuck's other queries in a separate follow up comment. ---------------------------------------------------------------------- Comment By: Charles Wilson (cwilso11) Date: 2008-03-28 21:11 Message: Logged In: YES user_id=1384893 Originator: NO I have updated the following components of the "MSYS Supplementary Tools: Technology Preview, Tools for MSYS-1.0.11" release, as requested: inetutils-1.3.2-40-MSYS-1.0.11-2-bin.tar.gz inetutils-1.3.2-40-MSYS-1.0.11-2-src.tar.gz openssl-0.9.8g-1-MSYS-1.0.11-2-bin.tar.gz openssl-0.9.8g-1-MSYS-1.0.11-2-dev.tar.gz openssl-0.9.8g-1-MSYS-1.0.11-2-dll098.tar.gz openssl-0.9.8g-1-MSYS-1.0.11-2-src.tar.gz openssh-4.7p1-MSYS-1.0.11-1-bin.tar.gz openssh-4.7p1-MSYS-1.0.11-1-src.tar.gz cvs-1.11.22-MSYS-1.0.11-1-bin.tar.gz cvs-1.11.22-MSYS-1.0.11-1-src.tar.gz vim-7.1-MSYS-1.0.11-1-bin.tar.gz vim-7.1-MSYS-1.0.11-1-src.tar.gz gmp-4.2.2-MSYS-1.0.11-1-dev.tar.gz gmp-4.2.2-MSYS-1.0.11-1-dll3.tar.gz gmp-4.2.2-MSYS-1.0.11-1-src.tar.gz guile-1.8.4-MSYS-1.0.11-1-bin.tar.gz guile-1.8.4-MSYS-1.0.11-1-dev.tar.gz guile-1.8.4-MSYS-1.0.11-1-dll17.tar.gz guile-1.8.4-MSYS-1.0.11-1-doc.tar.gz guile-1.8.4-MSYS-1.0.11-1-src.tar.gz autogen-5.9.2-MSYS-1.0.11-1-bin.tar.gz autogen-5.9.2-MSYS-1.0.11-1-dev.tar.gz autogen-5.9.2-MSYS-1.0.11-1-dll25.tar.gz autogen-5.9.2-MSYS-1.0.11-1-src.tar.gz This completes the repackaging of my MSYS-related contributions, which formerly installed into /usr. Note that these new packages follow the newly-proposed naming convention. This may be premature -- so I am not going to re-repackage those components updated on 3/25, until the naming convention issue is resolved. At that time, I'll take whatever action is necessary...but perhaps not quite in such a rush. <g> I have not addressed the 'lpr' package. I have not yet addressed the 'native' autotool packages which install into /usr/local; need to resolve questions raised in 2008-03-25 22:34 comment. I have (or will, very soon) removed the "old" versions of all updated packages. ---------------------------------------------------------------------- Comment By: Charles Wilson (cwilso11) Date: 2008-03-25 22:34 Message: Logged In: YES user_id=1384893 Originator: NO I have updated the following components of the "MSYS System Builder: Technology Preview, msysDVLPR-1.0.0-alpha-1" release, as requested: autoconf-2.61-MSYS-1.0.11-1-src.tar.bz2 autoconf-2.61-MSYS-1.0.11-1.tar.bz2 automake-1.10-MSYS-1.0.11-1-src.tar.bz2 automake-1.10-MSYS-1.0.11-1.tar.bz2 libtool1.5-1.5.25a-20070701-MSYS-1.0.11-1-src.tar.bz2 libtool1.5-1.5.25a-20070701-MSYS-1.0.11-1.tar.bz2 termcap-20050421-MSYS-1.0.11-1-src.tar.bz2 termcap-20050421-MSYS-1.0.11-1.tar.bz2 However, I have not (yet) removed the old versions (whose filenames all have the pattern *-MSYS-1.0.11.tar.bz2 and *-MSYS-1.0.11-src.tar.bz2 -- that is, the old versions do not contain a "-1" modifier) I have updated the following components of the "MSYS Base System: Technology Preview MSYS-1.0.11" release, as requested: make-3.81-MSYS-1.0.11-2-src.tar.bz2 make-3.81-MSYS-1.0.11-2.tar.bz2 csmake-3.81-MSYS-1.0.11-2-src.tar.bz2 csmake-3.81-MSYS-1.0.11-2.tar.bz2 texinfo-4.11-MSYS-1.0.11-1-src.tar.bz2 texinfo-4.11-MSYS-1.0.11-1.tar.bz2 However, I have not (yet) removed the old versions [cs]make-3.81-MSYS-1.0.11-1* and texinfo-4.11-MSYS-1.0.11[-src].tar.bz2. Also, I added a manifest resource to texinfo's install-info.exe so it will not be automatically privilege-escalated by Vista's UAC. I hope. I have updated the following components of the "MSYS Supplementary Tools: Technology Preview, Tools for MSYS-1.0.11" release, as requested: zlib-1.2.3-MSYS-1.0.11-1-src.tar.bz2 zlib-1.2.3-MSYS-1.0.11-1.tar.bz2 gdbm-1.8.3-MSYS-1.0.11-1-src.tar.bz2 gdbm-1.8.3-MSYS-1.0.11-1.tar.bz2 lndir-6.8.1.0-MSYS-1.0.11-1-src.tar.bz2 lndir-6.8.1.0-MSYS-1.0.11-1.tar.bz2 perl-5.6.1-MSYS-1.0.11-1-src.tar.bz2 perl-5.6.1-MSYS-1.0.11-1.tar.bz2 perl-man-5.6.1-MSYS-1.0.11-1.tar.bz2 libiconv-1.11-MSYS-1.0.11-1-src.tar.bz2 libiconv-1.11-MSYS-1.0.11-1.tar.bz2 gettext-0.16.1-MSYS-1.0.11-1-src.tar.bz2 gettext-0.16.1-MSYS-1.0.11-1.tar.bz2 gettext-devel-0.16.1-MSYS-1.0.11-1.tar.bz2 regex-0.12-MSYS-1.0.11-1-src.tar.bz2 regex-0.12-MSYS-1.0.11-1.tar.bz2 crypt-1.1-1-MSYS-1.0.11-1-src.tar.bz2 crypt-1.1-1-MSYS-1.0.11-1.tar.bz2 minires-1.01-1-MSYS-1.0.11-1-src.tar.bz2 minires-1.01-1-MSYS-1.0.11-1.tar.bz2 flex-2.5.33-MSYS-1.0.11-1-src.tar.bz2 flex-2.5.33-MSYS-1.0.11-1.tar.bz2 bison-2.3-MSYS-1.0.11-1-src.tar.bz2 bison-2.3-MSYS-1.0.11-1.tar.bz2 However, I have not (yet) removed the old versions (whose filenames all have the pattern *-MSYS-1.0.11.tar.bz2 and *-MSYS-1.0.11-src.tar.bz2 -- that is, the old versions do not contain a "-1" modifier) >From Keith's list, that leaves: inetutils openssl openssh cvs vim gmp guile autogen lpr [not me] in /usr, and the packages listed in Keith's message on 2008-03-14 06:53 in /usr/local. I will address those as soon as I accumulate enough roundtuits. I am actually rebuilding all of these packages, and updating the embedded build scripts to package them "correctly". However, I ran into two anomalies: (1) the automake build goes into an infloop during 'make install' if the non-case-sensitive make is used. I had to use csmake. This is probably a bug in automake's own makefiles, but I didn't have time to track it down. (2) the msys gcc (gcc-2.95.3) has /usr/local/include and /usr/local/lib in its specs. This means that /usr/local/include/iconv.h was used when compiling gettext, and apps were linked against /usr/local/lib/libiconv.dll.a (or they were, until I took drastic steps). This is bad, because I'm trying to build msys tools but was linking against native libraries. For now, I added code the the build scripts to detect the problem and warn the user: "please move /usr/local/include and /usr/local/lib out of the way". However, the true solution requires some discussion: Perhaps the "native" (auto)tools and their libraries/headers should NOT go into /usr/local (or /local, whatever) at all. The mingw gcc does not include "/usr/local/anything" in its specs, so if a user wants to link against the native libiconv, they have to explicitly say -L/usr/local/lib and -I/usr/local/include (which of course get turned into -IC:\<...>\local\include and -LC:\<...>\local\lib by msys, before handing off to mingw gcc) anyway. So, putting the tools into /usr/lcoal serves no real benefit -- except that /usr/local/bin is usually in everybody's PATH somewhere. OTOH, unless we roll out a new msys-gcc with a modified specs, putting "native" stuff into /usr/local is asking for trouble, when you're trying to build msys tools. OTO-OTHER-H, there are only about five people on the planet who ever do that. However, if I rebuild the "native" autotools for a different prefix, what should I choose? /mingw/local? (But if somebody installs msys before mingw, and hasn't set up their mount table, this could get hidden by later mount table manipulations). '/native'? '/win32'? Any other ideas? Finally, there is the issue of the msys-gcc itself. Recently, we had a new release of gcc-3.4.5 specifically to deal with vista problems. Do we need to backport whatever that fix was, to gcc-2.95.3? Is anybody willing to take on the pain of creating an msys-gcc-3.4.5 package (or msys-gcc-favorite-newer-version)? Once XP disappears from common use, are we going to be stuck without a way to (re)build msys tools? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-03-14 06:53 Message: Logged In: YES user_id=823908 Originator: YES After some further consideration, I'm not entirely sure how best to deal with those packages intended for installation in /usr/local. Certainly, we should strip the initial `usr/' off the path recorded in the tarball, but I'm thinking that maybe the entire `usr/local/' should be stripped. My rationale is that the end user may have mapped a physical path, outside of the MSYS tree, to /usr/local via the MSYS mount table, (I do this, so I can share a single /usr/local among multiple MSYS installations, or more usefully, to switch to an alternative /usr/local tree, to facilitate package testing). The advantage to be gained, by stripping the entire `usr/local/' prefix away, would be that one can unpack the tarball directly into the physical directory mapped to /usr/local, and everything will be installed in the correct place. The disadvantage would be, that for a completely standard installation, if the user were to unpack the tarball in the MSYS root, then everything will be installed in the wrong place, potentially overwriting files which do correctly belong in /bin say, with alternatives which should have gone in /usr/local/bin. On balance, I think it is probably better to leave the `local/' prefix in place, to protect a completely standard installation, (with /usr/local mapping through the default loopback mount, to /local), from inadvertent corruption. This might make things slightly more difficult for the user who prefers to map /usr/local elsewhere, but hopefully any user adopting this strategy will be sufficiently competent to deal with the issues. Comments? For the record, the affected subset of those packages already identified is: autoconf-4-1-bin.tar.bz2 autoconf2.1-2.13-3-bin.tar.bz2 autoconf2.5-2.61-1-bin.tar.bz2 automake-3-1-bin.tar.bz2 automake1.10-1.10-1-bin.tar.bz2 automake1.9-1.9.6-2-bin.tar.bz2 gettext-0.16.1-1-bin.tar.bz2 gettext-0.16.1-1-dll.tar.bz2 libiconv-1.11-1-bin.tar.bz2 libiconv-1.11-1-dll.tar.bz2 libtool1.5-1.5.25a-1-bin.tar.bz2 libtool1.5-1.5.25a-1-dll.tar.bz2 All of the above are in the `MSYS Supplementary Programs' package set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1913543&group_id=2435 |