[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4 files not unique in 8.3 environments

From: Eli Zaretskii
Subject: Re: m4 files not unique in 8.3 environments
Date: Sat, 26 Feb 2005 18:16:26 +0200

> From: Bruno Haible <address@hidden>
> Date: Sat, 26 Feb 2005 16:06:52 +0100
> >   ./config/inttypes-pri.m4
> >   ./config/inttypes.m4
> >   ./config/inttypes_h.m4
> >
> > This works fine for UNIX, but when people try to unpack the GNU make
> > tarball on a DOS system where only 8.3 filenames are allowed they get
> > errors because these filenames are not unique in 8.3.
> Is this still relevant? The successor of the DOS filesystem, VFAT, was
> shipped since 1995. That's 10 years ago.

Even under VFAT, these file names might still clash, because when the
tarball is unpacked, Windows creates the 8+3 aliases for the long file
names.  Under some Windows configurations, these aliases will clash
and cause trouble.

In addition, there's the DOSEmu emulator (part of GNU/Linux systems)
which doesn't yet support long file names, and so is limited to 8+3
file names.

> The DJGPP support in gettext has not seen a volunteer caring about
> it for 3 years.

Even if the DJGPP port of gettext itself is not actively maintained,
the gettext files do wind up in other packages that use GNU Gettext.
(That's how Paul became acquainted with this issue.)

If you need a DJGPP-knowledgeable person to help you find solutions
for related problems, you will find them on address@hidden

> This constellation (inttypes-pri.m4, inttypes.m4, inttypes_h.m4) exists
> since gettext 0.11.4 - 2.5 years ago. Yet you are the first one to complain
> about it.

It was I who complained.  And I only did that now because AFAIK the
Make 3.81 is the first version that I port that has these files.

Could you please find a solution to these two file names?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]