Bugs item #1913543, was opened at 2008-03-13 14:17
Message generated for change (Comment added) made by keithmarshall
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: Keith Marshall (keithmarshall)
Date: 2008-04-30 19: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 16: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-29 01: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-26 02: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 10: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
|
