Menu
▾
▴
mingw-users
|
From: Charles W. <cwi...@us...> - 2007-09-12 21:09:23
|
Keith said:
> On Wed, 2007-09-12 at 18:55 +0200, David Lucena wrote:
>> Is there any planning to provide msys DTK tools binaries in a
>> compressed package instead of an .exe windows installer?
>
> That's how I would like to do it, in future; just post the updates as
> separate files, as many of them already are. I don't plan to offer any
> further releases of msysDTK, in the form of an integrated installer.
I have been working on this, for MSYS-1.0.11, against Cesar's most
recent kernel. So far, I've got:
zlib-1.2.3 (+dll)
gdbm-1.8.3 (+dll)
perl-5.6.1
not an update to the holy grail of 5.8.x or 5.9.x; just recompiled
with DLL support and additional patches backported from the cygwin
5.8.8 package. It includes CPAN stuff installed into
/usr/lib/perl5/vendor_perl/5.6/, leaving site_perl/5.6/ free for user
packages.
lndir
This was not part of the original msysDTK, but I needed this simple
tool for building some of these packages out-of-tree, so...
autoconf-2.61
customized with *-*-msys* config.guess/config.sub support
automake-1.10
customized with *-*-msys* config.guess/config.sub support
libtool-1.5.25a
customized with *-*-msys* support throughout
includes msys-ltdl-3.dll
This way, I can do 'autoreconf -f -v -r' in some package, and it will
Just Build(tm) for msys -- so long as I'm in an msysDVLPR shell.
libiconv-1.11
No DLL. Bruno's fancy schmancy mechanism to build DLLs on Woe32
doesn't work with gcc-2.95.3.
gettext-0.16.1
No DLL. see above. This package is needed because it is now
considered one of the autotools. So, to reautoconf make-3.81, I
needed a working autopoint -- which means gettext. Even though I
configured my 'make' --without-nls. Sigh. Anyway, the various .m4
files that reference *-*-cygwin* now also reference *-*-msys*.
gmp-4.2.1
DLL. This is required by guile-1.8.2, and since guile was part of
the original msysDTK (because it, in turn, was needed for 'autogen'
All are packaged separately, with -src tarballs, which contain (usually)
pristine source, some patches, and a build script.
Next up: guile, autogen, cvs[*], inetutils, openssl, openssh.
> which you
>find in the `MSYS: Supplementary Tools' section of the download page,
>(or in the `Snapshots/MSYS' section, for that matter).
Which is where I plan to upload these new versions.
Also, see my post in today's "mingw32-make VS msys make. PLUS msys make
3.80?" thread.
NOTE concerning the autotools: end-users should really also have
mingwPORTs of these tools installed in their /mingw (or /usr/local,
PROVIDED /usr/local/bin precedes /bin in PATH). While autoconf and
automake are platform-agnostic, libtool is not. So /bin/libtool is
pre-configured for msys, not mingw (and that's why there is an
msys-ltdl-3.dll). Worse: autotools expect to "work together" -- so if
you use /bin/libtoolize, you're probably also going to be using
/bin/aclocal, which looks in /share/aclocal -- and finds stuff
corresponding to *msys* related libraries (like /lib/libintl.a)
I plan to package up the following as mingwPORTs, but also as
pre-"compiled" packages for /usr/local/
autoconf (wrapper) from gentoo
autoconf-2.13
autoconf-2.61
automake (wrapper) from gentoo
automake-1.9, 1.10 (others if demand)
libtool-1.5.25a
Given this, I think the next msysDTK should include these seven+
pre-compiled packages, and NOT the ones listed way up above. Those
should instead be part of a new msysDVLPR toolkit. (Which would mean
that the default /etc/profile should do this:
/bin:/usr/local/bin:/mingw/bin:${PATH}
for msysDVLPR, instead of
/usr/local/bin:/bin:/mingw/bin:${PATH}
which it does now)
But that's just IMO.
--
Chuck
[*] There's something wrong with the cvs-1.11.22-msys packages that were
posted a few weeks ago. When I tried to use autopoint (which internally
expects a working cvs binary) it failed miserably. Replacing the
cvs-1.11.22 cvs.exe with the ancient cvs-1.11.0 version from the
original msysDTK, and all was well.
|
|
From: Cesar S. <ces...@gm...> - 2007-09-18 00:29:02
|
Charles Wilson wrote: > Keith said: >> On Wed, 2007-09-12 at 18:55 +0200, David Lucena wrote: >>> Is there any planning to provide msys DTK tools binaries in a >>> compressed package instead of an .exe windows installer? >> That's how I would like to do it, in future; just post the updates as >> separate files, as many of them already are. I don't plan to offer any >> further releases of msysDTK, in the form of an integrated installer. > > I have been working on this, for MSYS-1.0.11, against Cesar's most > recent kernel. So far, I've got: [...] > > > autoconf-2.61 > customized with *-*-msys* config.guess/config.sub support > > automake-1.10 > customized with *-*-msys* config.guess/config.sub support > > libtool-1.5.25a > customized with *-*-msys* support throughout > includes msys-ltdl-3.dll > > This way, I can do 'autoreconf -f -v -r' in some package, and it will > Just Build(tm) for msys -- so long as I'm in an msysDVLPR shell. > I like the idea. I'm currently using the Earnie's cygwin2msys script (basically sed "s/cygwin/msys/") from the dvlpr CVS tree, but I would like to try your approach. [...] > Those should instead be part of a new msysDVLPR toolkit. I also agree these should go to the msysDVLPR toolkit. Perhaps they could live as releases of the "MSYS: System Builder" package on the SF download page. > > But that's just IMO. > > -- > Chuck Likewise. Cesar |
|
From: Keith M. <kei...@us...> - 2007-09-18 20:27:33
|
On Mon, 2007-09-17 at 20:40 -0300, Cesar Strauss wrote: > > Those should instead be part of a new msysDVLPR toolkit. > > I also agree these should go to the msysDVLPR toolkit. Perhaps they > could live as releases of the "MSYS: System Builder" package on the SF > download page. Yes, that is exactly where they should go. Maybe not as separate "releases", but as a collection of separate tarballs, within one of `Technology Preview', `Release Candidate', `Current Release' and `Previous Release' "release collections", so we don't lose dozens of current tarballs in the mire of `View older releases...'. Thanks, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-20 05:50:35
|
Keith Marshall wrote: > On Mon, 2007-09-17 at 20:40 -0300, Cesar Strauss wrote: >>> Those should instead be part of a new msysDVLPR toolkit. >> I also agree these should go to the msysDVLPR toolkit. Perhaps they >> could live as releases of the "MSYS: System Builder" package on the SF >> download page. > > Yes, that is exactly where they should go. Maybe not as separate > "releases", but as a collection of separate tarballs, within one of > `Technology Preview', `Release Candidate', `Current Release' and > `Previous Release' "release collections", so we don't lose dozens of > current tarballs in the mire of `View older releases...'. I added to the existing "MSYS: System Builder|Technology Preview: msysDVLPR-1.0.0-alpha-1" package|release, the following tarballs which unpack into /usr: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=227249&release_id=536830 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 autoconf-2.61-MSYS-1.0.11-src.tar.bz2 automake-1.10-MSYS-1.0.11-src.tar.bz2 libtool1.5-1.5.25a-20070701-MSYS-1.0.11-src.tar.bz2 These ^^^ are the "I know about msys" versions. I added to the existing "MSYS: Supplementary Tools" package, in a new "Technology Preview: Tools for MSYS-1.0.11" release, the following tarballs which unpack into /usr (and in some cases, /usr/local -- see the notes): http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879&release_id=540763 autoconf-4-1-bin.tar.bz2 /usr/local (wrapper) autoconf2.1-2.13-3-bin.tar.bz2 /usr/local autoconf2.5-2.61-1-bin.tar.bz2 /usr/local automake-3-1-bin.tar.bz2 /usr/local (wrapper) automake1.9-1.9.6-2-bin.tar.bz2 /usr/local automake1.10-1.10-1-bin.tar.bz2 /usr/local libtool1.5-1.5.25a-1-bin.tar.bz2 /usr/local libtool1.5-1.5.25a-1-dll.tar.bz2 /usr/local libiconv-1.11-1-bin.tar.bz2 /usr/local libiconv-1.11-1-dll.tar.bz2 /usr/local gettext-0.16.1-1-bin.tar.bz2 /usr/local gettext-0.16.1-1-dll.tar.bz2 /usr/local libiconv-1.11-MSYS-1.0.11.tar.bz2 /usr, MSYS-linked gettext-0.16.1-MSYS-1.0.11.tar.bz2 /usr, MSYS-linked gettext-devel-0.16.1-MSYS-1.0.11.tar.bz2 /usr, MSYS-linked crypt-1.1-1-MSYS-1.0.11.tar.bz2 /usr, ditto... gdbm-1.8.3-MSYS-1.0.11.tar.bz2 /usr, ... inetutils-1.3.2-36-MSYS-1.0.11.tar.bz2 /usr gmp-4.2.1-MSYS-1.0.11.tar.bz2 /usr lndir-6.8.1.0-MSYS-1.0.11.tar.bz2 /usr minires-1.01-1-MSYS-1.0.11.tar.bz2 /usr openssh-4.6p1-MSYS-1.0.11.tar.bz2 /usr openssl-0.9.8e-3-MSYS-1.0.11.tar.bz2 /usr regex-0.12-MSYS-1.0.11.tar.bz2 /usr zlib-1.2.3-MSYS-1.0.11.tar.bz2 /usr perl-5.6.1-MSYS-1.0.11.tar.bz2 /usr perl-man-5.6.1-MSYS-1.0.11.tar.bz2 /usr autoconf-4-1-src.tar.bz2 autoconf2.1-2.13-3-src.tar.bz2 autoconf2.5-2.61-1-src.tar.bz2 automake-3-1-src.tar.bz2 automake1.9-1.9.6-2-src.tar.bz2 automake1.10-1.10-1-src.tar.bz2 libtool1.5-1.5.25a-1-src.tar.bz2 libiconv-1.11-MSYS-1.0.11-src.tar.bz2 libiconv-1.11-1-src.tar.bz2 gettext-0.16.1-MSYS-1.0.11-src.tar.bz2 gettext-0.16.1-1-src.tar.bz2 crypt-1.1-1-MSYS-1.0.11-src.tar.bz2 gdbm-1.8.3-MSYS-1.0.11-src.tar.bz2 inetutils-1.3.2-36-MSYS-1.0.11-src.tar.bz2 gmp-4.2.1-MSYS-1.0.11-src.tar.bz2 lndir-6.8.1.0-MSYS-1.0.11-src.tar.bz2 minires-1.01-1-MSYS-1.0.11-src.tar.bz2 openssh-4.6p1-MSYS-1.0.11-src.tar.bz2 openssl-0.9.8e-3-MSYS-1.0.11-src.tar.bz2 regex-0.12-MSYS-1.0.11-src.tar.bz2 zlib-1.2.3-MSYS-1.0.11-src.tar.bz2 perl-5.6.1-MSYS-1.0.11-src.tar.bz2 Missing from this package dump, but present in the old msysDTK-1.0.1, are: cvs guile autogen I also believe that the bison-2.3 and flex-2.5.33 components currently in "Snapshot|MSYS", should really be part of this new "MSYS: Supplementary Tools|Technology Preview: Tools for MSYS-1.0.11" release. But first somebody is going to have to get them GPL-compliant with -src packages. And maybe build recipes... (and obviously, once we get an actual, working, updated version of cvs in MSYS: Supplementary Tools|Technology Preview: Tools for MSYS-1.0.11", the broken one currently in "Snapshot|MSYS" should be removed/obsoleted/hidden or whatever the FRS will allow). I've got guile built and *probably* ready to go -- it passes almost all of its own testsuite -- but I can't get autogen to work yet without coredumping inside guile. This problem also happens with guile/autogen on cygwin...so...well, I'll keep working on it. http://www.mail-archive.com/aut...@li.../msg00077.html cvs-1.11.22 (as I reported earlier and as someone else reported today) is broken on MSYS. I'm not sure what the problem is (or I'd've fixed it already) but I suspect that various workarounds for cygwin in the cvs code have been removed as "real" cygwin has improved. However, msys is still basically cygwin-1.3.x so it still needs those workarounds (I found this to be the case with openssh, as well -- Corinna has been doing a bang-up job removing all those cygwin-specific hacks in openssh -- which I had to put back in to get it to work on msys...sigh). If someone else would like to look into the cvs-1.11.22 issue, that'd be a big help... -- Chuck |
|
From: Keith M. <kei...@us...> - 2007-09-20 20:51:22
|
On Thu, 2007-09-20 at 01:49 -0400, Charles Wilson wrote: > I added to the existing "MSYS: System Builder|Technology Preview: > msysDVLPR-1.0.0-alpha-1" package|release, the following tarballs which > unpack into /usr: [...] > I added to the existing "MSYS: Supplementary Tools" package, in a new > "Technology Preview: Tools for MSYS-1.0.11" release, the following > tarballs which unpack into /usr (and in some cases, /usr/local -- see > the notes): [...] Two impressive lists, Chuck! I haven't had time to play with them yet, but many thanks for your efforts. Just one question: do these > libiconv-1.11-1-bin.tar.bz2 /usr/local > libiconv-1.11-1-dll.tar.bz2 /usr/local > libiconv-1.11-MSYS-1.0.11.tar.bz2 /usr, MSYS-linked > libiconv-1.11-MSYS-1.0.11-src.tar.bz2 > libiconv-1.11-1-src.tar.bz2 include Bruno's patch, which I added to http://downloads.sourceforge.net/mingw/libiconv-1.11-mingwPORT-20070423-1.tar.bz2 and which is essential to have wchar_t conversions work correctly? If not, could you apply it please? Regards, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-21 03:05:45
|
Keith Marshall wrote: > Two impressive lists, Chuck! I haven't had time to play with them yet, > but many thanks for your efforts. > > Just one question: do these > include Bruno's patch, which I added to > http://downloads.sourceforge.net/mingw/libiconv-1.11-mingwPORT-20070423-1.tar.bz2 > and which is essential to have wchar_t conversions work correctly? > >> libiconv-1.11-1-bin.tar.bz2 /usr/local >> libiconv-1.11-1-dll.tar.bz2 /usr/local >> libiconv-1.11-1-src.tar.bz2 Yes. >> libiconv-1.11-MSYS-1.0.11.tar.bz2 /usr, MSYS-linked >> libiconv-1.11-MSYS-1.0.11-src.tar.bz2 No. (Explanation: I did the MSYS ones first. Only later did I look at your libiconv mingwPORT, since it was newer than the one I posted a year or so ago. BTW, components in release that install into /usr/local are all bastardized mingwPORTs, set up to do DESTDIR installs and then package themselves up into tarballs.) Well, except for libiconv-usr/local and gettext-usr/local. Those were tricky. With true "MSYS" packages, DESTDIR "just works". For the /usr/local versions of autoconf/automake/libtool, you actually configure those with MSYS-style --prefix settings [*], so again, DESTDIR "just works". But the libiconv-usr/local and gettext-usr/local packages must be configured as true win32 native ports, which means --prefix=`cd foo && pwd -W`. And then, DESTDIR breaks, no matter how you specify it: install .... $(DESTDIR)$(prefix)/bin becomes one of: install .... /tmp/foo/C:/blah/blah/foo install .... C:/TEMP/foo/C:/blah/blah/foo Bang. You lose. So, instead, libiconv-usr/local and gettext-usr/local are configured as fully "relocatable" packages (--enable-relocatable), with prefix tmpdir=`mktemp -d "/var/tmp/libiconv-XXXXXX"` `cd /var/tmp/${tmpdir}/usr/local && pwd -W` or: C:/msys/1.0/var/tmp/libiconv-nnnnnn/usr/local and I actually do a real install into that temporary directory. But the tarball is created from /var/tmp/libiconv-nnnnnn, so users will actually install into /usr/local. The beauty of this is that the relocation machinery will handle matching the final subdirpath no matter where the end user has installed msys, without any reference to the msys mount table at all. So even if Suzy has msys in D:/freeware/msys/1.0, so that libiconv-2.dll ends up in D:/freeware/msys/1.0/local/bin/libiconv-2.dll the relocation magic will compare the real and expected paths: D:/freeware/msys/1.0/local/bin/libiconv-2.dll C:/msys/1.0/var/tmp/libiconv-nnnnnn/usr/local/bin/libiconv-2.dll ^ and match things up at the marker, and figure out all appropriate paths relative to that. So, in effect, ALL of the precompiled auto*/libtool/libiconv/gettext components that I've compiled for mingw-usr/local use are insensitive to the actual installation path of msys. [*] because these packages are just scripts, which are executed by MSYS tools like msys-perl or msys-bash. Therefore, internally, paths need to be in unix format -- contrary to old recipes for autotool mingwPORTs that suggested using the typical --prefix=`cd foo && pwd -W`. > If > not, could you apply it please? I'll update the MSYS libiconv components. What's the policy (and what does FRS allow) for this sort of thing? There's really no reason to keep the buggy/bad version in the Package|Release, but I've heard that it's almost impossible to actually remove a file from FRS. Which means that the new upload obviously must have a new name...so I was thinking: libiconv-1.11-MSYS-1.0.11* --> libiconv-1.11-1-MSYS-1.0.11* --> libiconv-1.11-2-MSYS-1.0.11* etc. But once I upload the new files and add them to the existing Package|Release, can I "hide" the old versions? Reassign them to a different (hidden) Package|Release? -- Chuck |
|
From: Charles W. <cwi...@us...> - 2007-09-22 00:06:51
|
Charles Wilson wrote: > Keith Marshall wrote: >> Just one question: do these > > include Bruno's patch, which I added to > > > http://downloads.sourceforge.net/mingw/libiconv-1.11-mingwPORT-20070423-1.tar.bz2 > > and which is essential to have wchar_t conversions work correctly? >> If >> not, could you apply it please? > > I'll update the MSYS libiconv components. Actually, on further thought: should I do this for the MSYS version? The patch itself says: +#if __STDC_ISO_10646__ || ((defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__) But generally, MSYS is more-or-less == CYGWIN. Under that assumption, the change in the patch would have no effect... -- Chuck |
|
From: Keith M. <kei...@us...> - 2007-09-22 08:57:50
|
On Fri, 2007-09-21 at 20:06 -0400, Charles Wilson wrote: > > I'll update the MSYS libiconv components. > > Actually, on further thought: should I do this for the MSYS version? > The patch itself says: > > +#if __STDC_ISO_10646__ || ((defined _WIN32 || defined __WIN32__) && > !defined __CYGWIN__) > > But generally, MSYS is more-or-less == CYGWIN. Under that assumption, > the change in the patch would have no effect... I don't know. I discovered the problem when I ran the `gencat' tool, out of the `catgets' package I mentioned yesterday, against the message catalogue sources in `man-1.6e'. Several of them -- mostly those for Eastern European languages -- blew up on finding character codes which weren't valid in cp1232, (my system codepage). I'd used libiconv, specifically to avoid dependency on the system codepage, yet here it was, screwing things up! I guess we could use this `gencat', built as an MSYS component, on those same message catalogue sources, to check if there will be a problem with your MSYS builds, but I don't have a platform on which I can do this. Perhaps the existing patch will not suffice for MSYS; but first, let's ascertain if there is a problem, or not. Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2007-09-22 14:14:17
|
On Sat, 2007-09-22 at 09:57 +0100, Keith Marshall wrote: > Several of them -- mostly those for Eastern European languages -- blew > up on finding character codes which weren't valid in cp1232, ... Oops. Of course, that should read `cp1252' -- sorry for the typo. > (my system codepage). Regards, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-22 20:23:00
|
Keith Marshall wrote:
> On Fri, 2007-09-21 at 20:06 -0400, Charles Wilson wrote:
> I guess we could use this `gencat', built as an MSYS component, on those
> same message catalogue sources, to check if there will be a problem with
> your MSYS builds, but I don't have a platform on which I can do this.
Well, this is harder than it sounds.
(1) the code often declares new variables after executable code within a
block (allowed by C99, not by C89). That's easy to fix.
(2) However, the 'struct index' declared in msgcat.h uses the "struct
hack" -- which is allowed by C99 and gcc-3.x. But not by gcc-2.95.3,
the MSYS compiler.
(3) MSYS does not expose _fmode. So, you have to link against binmode.o
instead -- but that's hard to manage, so I added -lbinmode to LIBS if
$host = msys, and manually created libbinmode.a:
ar cr /usr/lib/libbinmode.a /usr/lib/binmode.o
Anyway, I hacked things up enough to get gencat to compile, but
unsurprisingly it crashes when I try to process any message files, given
the quick-n-dirty "fix" to struct index.
See attached patch, which includes the results of running autoconf and
autoheader with (my) new auto*-MSYS packages, and the various code
changes and additions I needed even to get that far.
I'm really not sure how to get around #2, short of changing the whole
concept of the resizable catalog. But if you do that -- just for the
MSYS "port" -- then you're not really testing the mingw code. So you
won't learn what we want to learn: is the *libiconv* patch necessary on
MSYS.
> Perhaps the existing patch will not suffice for MSYS; but first, let's
> ascertain if there is a problem, or not.
Yeah, I'm going to let this one simmer. I might try building MSYS-groff
and MSYS-man-1.6e just to see if it works. But, I don't /really/ know
how to test/verify that the non-English catalogs are working --
especially as cygwin/msys use newlib, which has no intrinsic LC_*
support at all.
--
Chuck
|
|
From: Charles W. <cwi...@us...> - 2007-09-22 20:29:07
Attachments:
catgets-msys.patch.bz2
|
Charles Wilson wrote: > See attached patch It helps when you actually include the patch. bzip'ed because list wouldn't accept it otherwise. -- Chuck |
|
From: Keith M. <kei...@us...> - 2007-11-06 21:36:20
|
On Sat, 2007-09-22 at 16:28 -0400, Charles Wilson wrote: > Charles Wilson wrote: > > > See attached patch > > It helps when you actually include the patch. bzip'ed because list > wouldn't accept it otherwise. Chuck, I'm incorporating parts of your catgets patch. May I include your e-mail address in the ChangeLog? Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2007-09-22 22:54:57
|
On Sat, 2007-09-22 at 16:22 -0400, Charles Wilson wrote: > > On Fri, 2007-09-21 at 20:06 -0400, Charles Wilson wrote: > > I guess we could use this `gencat', built as an MSYS component, on > > those same message catalogue sources, to check if there will be a > > problem with your MSYS builds, but I don't have a platform on which > > I can do this. > > Well, this is harder than it sounds. > > (1) the code often declares new variables after executable code within > a block (allowed by C99, not by C89). That's easy to fix. That was accidental; thanks for pointing it out. There aren't *that* many instances, though! > (2) However, the 'struct index' declared in msgcat.h uses the "struct > hack" -- which is allowed by C99 and gcc-3.x. But not by gcc-2.95.3, > the MSYS compiler. Ah. Probably not something we need to worry about -- I expect this to only be distributed as a native library anyway. > (3) MSYS does not expose _fmode. So, you have to link against > binmode.o instead -- but that's hard to manage, so I added -lbinmode > to LIBS if $host = msys, and manually created libbinmode.a: > ar cr /usr/lib/libbinmode.a /usr/lib/binmode.o I didn't know this; thanks for pointing it out. Regards, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-22 20:39:51
|
Keith Marshall wrote: > Perhaps the existing patch will not suffice for MSYS; but first, let's > ascertain if there is a problem, or not. Final thought: when I built libiconv-MSYS (without the extra patch from Bruno), I actually ran the testsuite and it passed all of them. That indicates to me that libiconv-MSYS doesn't need any additional changes...notwithstanding that MSYS itself doesn't really support locales. Which is a good reason to NOT distribute any MSYS version of man, AND to default to the cmd console: that way, the native man + native libiconv + win32 codepage support + win32 cmd font support == internationalized man pages. I don't think you can get to that result within the "msys" arena. -- Chuck |
|
From: Keith M. <kei...@us...> - 2007-09-22 22:40:53
|
On Sat, 2007-09-22 at 16:39 -0400, Charles Wilson wrote: > > Perhaps the existing patch will not suffice for MSYS; but first, > > let's ascertain if there is a problem, or not. > > Final thought: when I built libiconv-MSYS (without the extra patch > from Bruno), I actually ran the testsuite and it passed all of them. > That indicates to me that libiconv-MSYS doesn't need any additional > changes...notwithstanding that MSYS itself doesn't really support > locales. Maybe, maybe not. I'm not sure that the testsuite caught this particular bug in any case. But don't waste any more time on it. I should have thought of this earlier; I had a simple test case when I submitted the bug report -- it would be much easier to build and verify that in MSYS, than getting gencat to build and run there. I'll have a look for that, or try to recreate it; it may still be on my machine at work. > Which is a good reason to NOT distribute any MSYS version of man, AND > to default to the cmd console: that way, the native man + native > libiconv + win32 codepage support + win32 cmd font support == > internationalized man pages. I don't think you can get to that result > within the "msys" arena. Sure. I never planned to make an MSYS build of man; I always planned to distribute it as a native app. But thanks for following up anyway. Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2007-09-24 20:05:38
Attachments:
testcase.c
|
On Sat, 2007-09-22 at 23:40 +0100, Keith Marshall wrote: > On Sat, 2007-09-22 at 16:39 -0400, Charles Wilson wrote: > > > Perhaps the existing patch will not suffice for MSYS; but first, > > > let's ascertain if there is a problem, or not. > > > > Final thought: when I built libiconv-MSYS (without the extra patch > > from Bruno), I actually ran the testsuite and it passed all of them. > > That indicates to me that libiconv-MSYS doesn't need any additional > > changes...notwithstanding that MSYS itself doesn't really support > > locales. > > Maybe, maybe not. I'm not sure that the testsuite caught this > particular bug in any case. But don't waste any more time on it. I > should have thought of this earlier; I had a simple test case when I > submitted the bug report... My original bug report may be found here: http://lists.gnu.org/archive/html/bug-gnu-libiconv/2007-04/msg00000.html Do note that I specifically reported that the libiconv test suite fails to catch this bug, so we cannot complacently assume that the bug is not present in your MSYS build, just because it passed all of its specified test cases. > ... -- it would be much easier to build and verify that in MSYS, than > getting gencat to build and run there. > > I'll have a look for that, or try to recreate it; it may still be on > my machine at work. I don't have the exact test case I posted in the bug report, but I do still have a similar one (attached); compile it with gcc -DICONV_CONST=const -o foo /usb/tmp/testcase.c -liconv If it runs silently, then this bug isn't apparent; it will complain if there is a problem. Regards, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-25 01:20:49
|
Keith Marshall wrote: >> I'll have a look for that, or try to recreate it; it may still be on >> my machine at work. > > I don't have the exact test case I posted in the bug report, but I do > still have a similar one (attached); compile it with > > gcc -DICONV_CONST=const -o foo /usb/tmp/testcase.c -liconv > > If it runs silently, then this bug isn't apparent; it will complain if > there is a problem. mingw works fine (using libiconv-1.11-1-bin.tar.bz2 and libiconv-1.11-1-dll.tar.bz2) cygwin (using cygwin's libiconv-1.11-1): $ ./testcase.exe iconv: Invalid or incomplete multibyte or wide character msys (using libiconv-1.11-MSYS-1.0.11.tar.bz2) $ ./testcase.exe 0 [main] testcaseX 2828 open_stackdumpfile: Dumping stack trace to testcaseX.exe.stackdump Segmentation fault (core dumped) So, there's obviously a bug that affects cygwin/msys -- it may be the same bug, just showing up in more...assertive form on msys. Unfortunately, this is going to be hard to debug, because gdb does not grok the debug information created by our old gcc-2.95.3. Might be quicker to try and figure out TRTD on cygwin, and then hope that same fix makes msys happy. -- Chuck |
|
From: Charles W. <cwi...@us...> - 2007-09-23 22:44:28
|
Charles Wilson wrote: > I added to the existing "MSYS: Supplementary Tools" package, in a new > "Technology Preview: Tools for MSYS-1.0.11" release, the following > tarballs which unpack into /usr (and in some cases, /usr/local -- see > the notes): > > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879&release_id=540763 > > Missing from this package dump, but present in the old msysDTK-1.0.1, are: > cvs > guile > autogen I've now added these three components to the release, and removed the (broken) cvs-1.11.22 from the "Snapshot|MSYS" package|release. (Actually, I moved the old cvs tarballs to the hidden "snapshot|msys" package|release). From the (updated) release notes: NOTES FOR SPECIFIC PACKAGES: ======================================================== cvs-1.11.22 Regression test results are only slightly worse than cvs-1.11.22 on cygwin-1.5.24-2. The differences relative to cygwin performance are intrinsic to msys' more windows-like default permissons handling: ** expected: -r--r----- .* ** got: -r--r--r-- <stuff> etc. guile-1.8.2: REQUIRES: msys-ltdl-3.dll from the libtool1.5-1.5.25a-20070701-MSYS-1.0.11.tar.bz2 component of the the "MSYS: System Builder" package, "Technology Preview: msysDVLPR-1.0.0-alpha-1" release. Passes almost all regression tests; however, there seems to be a bug in guile-1.8.2 with respect to cygwin and msys, which is tickled by autogen. That hasn't prevented cygwin from shipping 1.8.2 - and it DOES work perfectly for everything I've tried /except/ autogen. PORTING NOTE: static builds of guile are practically unmaintained on any platform, and don't seem to work on cygwin or msys. Therefore, this is a dynamic build. This is complicated on msys because the msys toolchain does not implement --enable-runtime-pseudo-relocs, but guile-1.8.2 in its distributed form requires that option on cygwin. Therefore, this version is patched to explicitly dllexport variables as is done for native windows builds. This means that all clients must -DSCM_IMPORT. autogen-5.9.2 Because guile is a dynamic build, so are the autogen libraries. And, just as guile clients must -DSCM_IMPORT, libopts clients must -DAO_IMPORT. autogen.exe coredumps on exit for any command (including --help or --version); something in the scheme/guile "atexit()" analogue goes haywire because of whatever autogen registers with that function. However, this occurs AFTER all processing is complete: so, the desired output files are (properly) created, but then autogen coredumps and exits with non-zero exit code. This behavior is similar to that observed on cygwin -- http://sourceforge.net/mailarchive/message.php?msg_name=1ca1c1410702231756j7af3ecc5t25986b31a86dae1f%40mail.gmail.com except on cygwin, the autogen process hangs and sucks 100% CPU -- at least /that/ doesn't occur on msys. Because this is an upstream bug and not, specifically, a problem with the msys port, and the autogen.exe program DOES work properly in that it produces the desired output, I consider this "good enough" -- but patches will be thoughtfully considered. So, IMO, we know have a complete replacement for everything that was in the old msysDTK package. There are still a few possible additions, tho: (1) msys-flex -- currently shows up as a Snapshot|MSYS component (which I take to mean "part of the upcoming msysCORE"). I don't think flex belongs in msysCORE -- but it does belong in the successor to msysDTK, IMO. (2) msys-bison -- ditto (3) msys-vim: Keith says he doesn't want to ship vi as a part of msysCORE anymore, but howls of outrage will follow as surely as night follows day if we drop it completely...even if we tell people to go use native-gvim. comments? -- Chuck |
|
From: Keith M. <kei...@us...> - 2007-09-23 23:10:28
|
On Sun, 2007-09-23 at 18:43 -0400, Charles Wilson wrote: > So, IMO, we know have a complete replacement for everything that was > in the old msysDTK package. You are a star, Chuck. Thanks for all your hard work. > There are still a few possible additions, tho: > > (1) msys-flex -- currently shows up as a Snapshot|MSYS component > (which I take to mean "part of the upcoming msysCORE"). I don't think that was ever Earnie's intention. Snapshot|MSYS is simply a relic of the old, and not entirely satisfactory package structure; it was used as a convenient place to stuff components as they were built, without any particular discrimination between what would end up in a CORE release, or in a new DTK collection. > I don't think flex belongs in msysCORE Nor do I. > -- but it does belong in the successor to msysDTK, IMO. I agree. > (2) msys-bison -- ditto Also agreed. > (3) msys-vim: Keith says he doesn't want to ship vi as a part of > msysCORE anymore, but howls of outrage will follow as surely as night > follows day if we drop it completely...even if we tell people to go > use native-gvim. I simply don't want the burden of maintaining it -- let's leave that to Bram Molenaar. I don't think it belongs in CORE anyway. If anyone does want to continue to maintain an MSYS specific version, I'll continue to distribute it as an add-on -- if not, I'll gladly leave it frozen, in its present state. Regardless, I will continue to use native-gvim. Regards, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-25 02:53:47
|
Keith Marshall wrote: >> There are still a few possible additions, tho: >> >> (1) msys-flex -- > >> I don't think flex belongs in msysCORE > > Nor do I. > >> -- but it does belong in the successor to msysDTK, IMO. > > I agree. > >> (2) msys-bison -- ditto > > Also agreed. I've added a fresh build of flex and bison to the "MSYS: Supplementary Tools|Technology Preview: Tools for MSYS-1.0.11" package|release. These are the same versions as those that were published in the "Snapshot|MSYS" package last August: flex-2.5.33 and bison-2.3. In particular, bison still fails the same tests it did last year: ERROR: 145 tests were run, 2 failed unexpectedly. 13 tests were skipped. ... [GNU Bison 2.3] testsuite: 31 33 failed Since these are basically the same as the -snapshot releases in Snapshot}MSYS -- but these actually obey the GPL by providing source! -- I removed the "older" files. >> (3) msys-vim: Keith says he doesn't want to ship vi as a part of >> msysCORE anymore, but howls of outrage will follow as surely as night >> follows day if we drop it completely...even if we tell people to go >> use native-gvim. > > I simply don't want the burden of maintaining it -- let's leave that to > Bram Molenaar. I don't think it belongs in CORE anyway. If anyone does > want to continue to maintain an MSYS specific version, I'll continue to > distribute it as an add-on -- if not, I'll gladly leave it frozen, in > its present state. Regardless, I will continue to use native-gvim. Well, I spent some time on this, without success. I was able to get the compilation to succeed, install, etc -- for both vim 7.1 and the current vim-5.8 code in the mingw CVS repo. However, in *both* cases, the vim executable was non-functional: on launch, it immediately exited without any error code, error message or coredump. Nuthin'. (sure, 'vim --version' works, but not *editing*.) Under cygwin's strace, both worked fine. (because cygwin's strace is a native windows application, it can actually be used with msys-linked apps without locking up. Fat lot of good it did, tho.) I'm stumped, and msys-gdb + msys-gcc-2.95.3 == no source-level debugging. I tried -g, -ggdb -gstabs, -gstabs++, you name it. No joy. Have fun decoding asm instructions. Unless somebody else figures this out and contributes a port, I suggest going with: (1) use gvim (2) use the existing binary vim.exe from MSYS-1.0.10. -- Chuck |
|
From: Cesar S. <ces...@gm...> - 2007-09-25 16:30:09
|
Charles Wilson wrote: > Well, I spent some time on this, without success. I was able to get the > compilation to succeed, install, etc -- for both vim 7.1 and the current > vim-5.8 code in the mingw CVS repo. > > However, in *both* cases, the vim executable was non-functional: on > launch, it immediately exited without any error code, error message or > coredump. Nuthin'. (sure, 'vim --version' works, but not *editing*.) I did build a functional vim from the mingw CVS repo. I don't think I needed any further patches. Did you install the termcap library from the CVS repo before building? Try installing this file as /etc/termcap: http://mingw.cvs.sourceforge.net/*checkout*/mingw/msys/dvlpr/etc/termcap?revision=1.1 I think I will prepare source packages with a build script and patches, such as you did on the msysDTK packages (it's a great idea, by the way). If it helps: $ vim --version VIM - Vi IMproved 5.8 (2001 May 31, compiled Jul 12 2007 22:52:22) Included patches: 1-9 Compiled with (+) or without (-): +autocmd -browse +builtin_terms +byte_offset +cindent +cmdline_compl +cmdline_info +comments +cryptv -cscope +dialog_con +digraphs -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path -osfiletype +find_in_path +fork() -GUI -hangul_input +insert_expand -langmap +linebreak +lispindent +menu +mksession +modify_fname +mouse -mouse_dec -mouse_gpm -mouse_netterm +mouse_xterm -multi_byte -perl -python +quickfix -rightleft +scrollbind +smartindent -sniff +statusline +syntax +tag_binary +tag_old_static -tag_any_white -tcl -terminfo +textobjects +title +user_commands +visualextra +viminfo +wildignore +wildmenu +writebackup -X11 -xfontset -xim -xterm_clipboard -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" fall-back for $VIM: "/usr/local/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -s -fnative-struct -fgnu-linker -finline-functions -mcpu=pentium Linking: gcc -o vim.exe -ltermcap Cesar |
|
From: Charles W. <cwi...@us...> - 2007-09-26 01:30:52
|
Cesar Strauss wrote: > Charles Wilson wrote: >> Well, I spent some time on this, without success. I was able to get the >> compilation to succeed, install, etc -- for both vim 7.1 and the current >> vim-5.8 code in the mingw CVS repo. >> >> However, in *both* cases, the vim executable was non-functional: on >> launch, it immediately exited without any error code, error message or >> coredump. Nuthin'. (sure, 'vim --version' works, but not *editing*.) > > I did build a functional vim from the mingw CVS repo. I don't think I > needed any further patches. > > Did you install the termcap library from the CVS repo before building? > Try installing this file as /etc/termcap: > http://mingw.cvs.sourceforge.net/*checkout*/mingw/msys/dvlpr/etc/termcap?revision=1.1 As it happens, the problem IS related to termcap -- the library, not the /etc file. Here's the story: I discovered that the info.exe program in the msys core snapshot (from texinfo-4.3) does NOT appear to do this (from the cygwin man page, texinfo-4.8a-1): The first non-option argument, if present, is the menu entry to start from; it is searched for in all `dir' files along INFOPATH. If it is not present, info merges all `dir' files and shows the result. Any remaining arguments are treated as the names of menu items relative to the initial node visited. What I observed was that only the first `dir' file found on the INFOPATH was used. So, I figured this was a new feature, added to texinfo sometime between 4.3 and 4.8a. So, I downloaded and built texinfo-4.11. And it coredumped. So, two programs built with my toolset, which has been working flawlessly until now, both died unexpectedly. What did they have in common? Both were the first tools I've built recently that used libtermcap.a -- which I built just prior to my vim experiments, from the msys CVS repo: http://mingw.cvs.sourceforge.net/mingw/msys/packages/termcap/ So, I downloaded the cygwin termcap package and built it (with a few necessary changes to allow re-autotooling. Plus, I updated the installable termcap database; IMO this new version is much better than the one in *checkout*/mingw/msys/dvlpr/etc/termcap -- I get *color* syntax highlighting instead of bold/underline, in the msys-rxvt window). Anyway, using this NEW libtermcap.a, I then rebuilt texinfo -- and it worked fine. Then, I tried rebuilding vim-7.1 -- and it, too, worked great -- I was even able to run vim's internal testsuite. (This build includes all 116 "official" patches, plus a forward port of the msys-vim-5.8 patch). So, I now have three new packages to upload for you, Cesar: termcap-20050421-MSYS-1.0.11.tar.bz2 (21K) texinfo-4.11-MSYS-1.0.11.tar.bz2 (401K) vim-7.1-MSYS-1.0.11.tar.bz2 (6.9M) termcap-20050421-MSYS-1.0.11-src.tar.bz2 (52K) texinfo-4.11-MSYS-1.0.11-src.tar.bz2 (1.7M) vim-7.1-MSYS-1.0.11-src.tar.bz2 (8.9M) > I think I will prepare source packages with a build script and patches, > such as you did on the msysDTK packages (it's a great idea, by the way). Thanks -- can't take credit, tho. It's a VERY stripped down version of what used to be a common method of packaging for cygwin: the "generic-build-script". http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/packaging/templates/generic-build-script?content-type=text/plain&cvsroot=cygwin-apps That one let you pick each stage of the build (prep, compile, install, pkg, etc) -- where as mine just "runs" from start to finish. I really like the gentoo-ebuild-inspired cygport method, and now use it almost exclusively for the packages I maintain for cygwin. But that requires a bit more infrastructure than we have in the msys environment. Anyway: I'm going to do the following: (1) upload the termcap component as part of the "MSYS: System Builder|Technology Preview: msysDVLPR-1.0.0-alpha-1 Notes" package|release. This is because the termcap library and header really aren't distributed with msysCORE -- they are just used when building msysCORE applications. (2) upload the texinfo component as part of the "Snapshot|MSYS" package|release, because info.exe and friends are part of msysCORE. (3) upload the vim component as part of the new (and gigantic) "MSYS: Supplementary Tools|Technology Preview: Tools for MSYS-1.0.11" package|release because it IS a supplementary tool, and because Keith doesn't want it in msysCORE anymore. Cesar, if you want to download the termcap and/or texinfo -src packages and update the corresponding locations in the cvs repo, that'd probably be a good idea. -- Chuck |
|
From: Keith M. <kei...@to...> - 2007-09-26 11:30:14
|
Charles Wilson wrote: > I discovered that the info.exe program in the msys core snapshot > (from texinfo-4.3) does NOT appear to do this (from the cygwin man > page, texinfo-4.8a-1): > > The first non-option argument, if present, is the menu > entry to start from; it is searched for in all `dir' files > along INFOPATH. If it is not present, info merges all `dir' > files and shows the result. Any remaining arguments are > treated as the names of menu items relative to the initial > node visited. > > What I observed was that only the first `dir' file found on the > INFOPATH was used. So, I figured this was a new feature, added to > texinfo sometime between 4.3 and 4.8a. ... There is certainly a bug in INFOPATH handling, in MSYS info-4.3, but I don't think this analysis is correct. $ info --version info (GNU texinfo) 4.3 $ echo $INFOPATH /info;/usr/local/info;/usr/local/share/info;/mingw/info $ info nonsuch [...output snipped...] This shows me the complete TOC for *all* info pages in *all* of those directories in $INFOPATH -- but note how I'm using *semicolons* as the PATH_SEPARATOR character, in my INFOPATH definition! If I change that, to use *colons*, (as I'd normally expect to do in MSYS), then I see a very much abridged TOC -- listing only those pages in /info. So, not a new feature since info-4.3, I think, but a PATH_SEPARATOR handling bug in the MSYS implementation of info-4.3. > So, I downloaded and built texinfo-4.11. : > [and], I now have three new packages to upload for you, Cesar: > > termcap-20050421-MSYS-1.0.11.tar.bz2 (21K) > texinfo-4.11-MSYS-1.0.11.tar.bz2 (401K) > vim-7.1-MSYS-1.0.11.tar.bz2 (6.9M) Excellent! The addition of a recent texinfo, in particular, will be very welcome. > Anyway: I'm going to do the following: > > (1) upload the termcap component as part of the "MSYS: System > Builder|Technology Preview: msysDVLPR-1.0.0-alpha-1 Notes" > package|release. This is because the termcap library and header > really aren't distributed with msysCORE -- they are just used when > building msysCORE applications. Yep, I see it there already. Thanks. > (2) upload the texinfo component as part of the "Snapshot|MSYS" > package|release, because info.exe and friends are part of msysCORE. I see it there already, but I'm wondering if it might not be better in a new `Technology Preview' collection, within `MSYS: Minimal System'; ultimately, I'd like to get rid of `Snapshot' as a distribution point. Leave this with me; I'll move it when I get back to that ongoing task of reorganising the downloads page. I'm also wondering if `MSYS: Base System' might not be a better name for this package collection? `MSYS: Minimal System' was a play on the meaning of the MSYS acronym, but is the tautology really appropriate? Any comments? > (3) upload the vim component as part of the new (and gigantic) "MSYS: > Supplementary Tools|Technology Preview: Tools for MSYS-1.0.11" > package|release because it IS a supplementary tool, and because Keith > doesn't want it in msysCORE anymore. I also see this is there already. Once again, thanks for all your hard work, Chuck. Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2007-09-21 19:52:13
|
On Thu, 2007-09-20 at 23:05 -0400, Charles Wilson wrote: > BTW, components in release that install into /usr/local are > all bastardized mingwPORTs, set up to do DESTDIR installs and then > package themselves up into tarballs.) > > Well, except for libiconv-usr/local and gettext-usr/local. Those > were > tricky. With true "MSYS" packages, DESTDIR "just works". For the > /usr/local versions of autoconf/automake/libtool, you actually > configure > those with MSYS-style --prefix settings [*], so again, DESTDIR "just > works". > > But the libiconv-usr/local and gettext-usr/local packages must be > configured as true win32 native ports, which means --prefix=`cd foo > && > pwd -W`. And then, DESTDIR breaks, no matter how you specify it: > install .... $(DESTDIR)$(prefix)/bin > becomes one of: > install .... /tmp/foo/C:/blah/blah/foo > install .... C:/TEMP/foo/C:/blah/blah/foo > Bang. You lose. Indeed. DESTDIR is an aberration, best avoided IMO. If you find a use for it, that you can't achieve equally easily by overriding `prefix' in the `make install phase, then you are doing something wrong. This: ./configure --prefix=`cd foo; pwd -W` ... make make prefix=/tmp/bar install just works anyway, provided you don't do anything insane with the other paths which should depend on `prefix', and provided the `make install' with an altered `prefix' doesn't force a rebuild, (which is forbidden by the GNU Coding Standards). > ... the relocation machinery will handle matching the final subdirpath > no matter where the end user has installed msys, without any reference > to the msys mount table at all. So even if Suzy has msys in > > D:/freeware/msys/1.0 > > so that libiconv-2.dll ends up in > > D:/freeware/msys/1.0/local/bin/libiconv-2.dll > > the relocation magic will compare the real and expected paths: > > D:/freeware/msys/1.0/local/bin/libiconv-2.dll > C:/msys/1.0/var/tmp/libiconv-nnnnnn/usr/local/bin/libiconv-2.dll > ^ > and match things up at the marker, and figure out all appropriate > paths relative to that. Yes, I'm using a similar technique for my `catgets' implementation, and for the `man' port; I use `_pgmptr' to locate the directory where the executable is installed, then, from the end of the path, I strip away any `/usr/bin', `/local/bin', `/usr/local/bin', (or their equivalents with `sbin' as the name of the leaf directory), and use whatever is left as a virtual file system root, from which to resolve any POSIX style absolute paths within the application. (I've got a handful of functions, which I've bundled into a library, to handle this path resolution; I'll make it available, when I've had a chance to review and tidy up the code). Regards, Keith. |
|
From: Charles W. <cwi...@us...> - 2007-09-22 00:03:50
|
Keith Marshall wrote: > Indeed. DESTDIR is an aberration, best avoided IMO. If you find a use > for it, that you can't achieve equally easily by overriding `prefix' in > the `make install phase, then you are doing something wrong. This: > > ./configure --prefix=`cd foo; pwd -W` ... > make > make prefix=/tmp/bar install > > just works anyway, provided you don't do anything insane with the other > paths which should depend on `prefix', and provided the `make install' > with an altered `prefix' doesn't force a rebuild, (which is forbidden by > the GNU Coding Standards). But "you" == "the maintainers of package foo" -- over whom "I" as a package-porter have no control. If the package uses automake, then I *know* that DESTDIR works -- everywhere but on native windows. I don't know if the foo-maintainers are idiots with regards to $(prefix) -- at least, not without doing a lot more research on 'foo'. > Yes, I'm using a similar technique for my `catgets' implementation, and > for the `man' port; I use `_pgmptr' to locate the directory where the > executable is installed, then, from the end of the path, I strip away > any `/usr/bin', `/local/bin', `/usr/local/bin', (or their equivalents > with `sbin' as the name of the leaf directory), and use whatever is left > as a virtual file system root, from which to resolve any POSIX style > absolute paths within the application. (I've got a handful of > functions, which I've bundled into a library, to handle this path > resolution; I'll make it available, when I've had a chance to review and > tidy up the code). All of the relocation machinery in libiconv and gettext is in the gnulib repository -- and I've actually used it to create a "relocatable" version of PROJ4 and libgeotiff. However, that was a LOT of work; it just isn't simple -- Bruno's machinery uses a lot of m4/configury/automake/actual-C-code to make it all work. Worse, PROJ4 and libgeotiff are MIT/X -- but gnulib code is [L]GPL. Which means my version of PROJ4 and libgeotiff are "promoted" to LGPL -- OK for me, not so good for many of those projects' main (commercial) clients. So my mods have a 0.0000% chance of being accepted. Sigh. -- Chuck |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X