[ANNOUNCEMENT] Updated: autoconf-archive-2023.02.20-1

Autoconf Archive has been updated to the latest upstream release 2023.02.20 on Cygwin. The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

[ANNOUNCEMENT] Updated: autoconf-archive-2022.09.03-1

Autoconf Archive has been updated to the latest upstream release 2022.09.03 on Cygwin. The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

Re: autoconf tests for iconv fail with undefined refs

On Sat, 19 Feb 2022 16:53:46 -0700, Brian Inglis > On 2022-02-19 16:37, Lemures Lemniscati wrote: > > On Sat, 19 Feb 2022 10:11:06 -0700, Brian Inglis > >> On 2022-02-18 22:26, Lemures Lemniscati wrote: > >>> On Fri, 18 Feb 2022 12:33:30 -0700, Brian Inglis > >

Re: autoconf tests for iconv fail with undefined refs

On 2022-02-19 16:37, Lemures Lemniscati wrote: On Sat, 19 Feb 2022 10:11:06 -0700, Brian Inglis On 2022-02-18 22:26, Lemures Lemniscati wrote: On Fri, 18 Feb 2022 12:33:30 -0700, Brian Inglis Any idea why autoconf tests for iconv now fail with undefined refs to iconv{_open,,_close}! >>

Re: autoconf tests for iconv fail with undefined refs

On Sat, 19 Feb 2022 10:11:06 -0700, Brian Inglis > On 2022-02-18 22:26, Lemures Lemniscati wrote: > > On Fri, 18 Feb 2022 12:33:30 -0700, Brian Inglis > >> Any idea why autoconf tests for iconv now fail with undefined refs to > >> iconv{_open,,_close}! STC attached,

Re: autoconf tests for iconv fail with undefined refs

On 2022-02-18 22:26, Lemures Lemniscati wrote: On Fri, 18 Feb 2022 12:33:30 -0700, Brian Inglis Any idea why autoconf tests for iconv now fail with undefined refs to iconv{_open,,_close}! STC attached, log, -E output. Tried also with -l iconv. https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg

Re: autoconf tests for iconv fail with undefined refs

On 2022-02-19 00:51, Lemures Lemniscati wrote: About libisocodes 1.2.4, these patches (attached) may help cygport-build. Thanks Lem, The first gets that build running, I already updated the second based on the checked in version. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Re: autoconf tests for iconv fail with undefined refs

On Fri, 18 Feb 2022 12:33:30 -0700, Brian Inglis > Any idea why autoconf tests for iconv now fail with undefined refs to > iconv{_open,,_close}! STC attached, log, -E output. Tried also with -l iconv. About libisocodes 1.2.4, these patches (attached) may help cygport-build. Lem

Re: autoconf tests for iconv fail with undefined refs

On Fri, 18 Feb 2022 12:33:30 -0700, Brian Inglis > Any idea why autoconf tests for iconv now fail with undefined refs to > iconv{_open,,_close}! STC attached, log, -E output. Tried also with -l iconv. https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=playground&id=3861 Hi, Brian.

autoconf tests for iconv fail with undefined refs

Any idea why autoconf tests for iconv now fail with undefined refs to iconv{_open,,_close}! STC attached, log, -E output. Tried also with -l iconv. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical

[ANNOUNCEMENT] Updated: autoconf-archive-2022.02.11-1

Autoconf Archive has been updated to the latest upstream release 2022-02-12 on Cygwin. The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

Re: [GOLDSTAR] Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

> On 12/5/2021 3:50 AM, Achim Gratz wrote: > > > > Autoconf has been updated to the latest upstream release 2.71, see the > > packaging notes below. Additionally the automake wrapper has been > > updated to the latest upstream version 15 (with some modifications for &

Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

On 12/5/2021 3:50 AM, Achim Gratz wrote: Autoconf upstream has stated that the 2.7x releases are not fully backwards compatible. Cygwin therefore chose to provide a new autoconf2.7 package (keeping autoconf2.5 available) and modifying the wrapper script to allow packaging systems to set

[GOLDSTAR] Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

On 12/5/2021 3:50 AM, Achim Gratz wrote: Autoconf has been updated to the latest upstream release 2.71, see the packaging notes below. Additionally the automake wrapper has been updated to the latest upstream version 15 (with some modifications for Cygwin). Great work, thanks for doing this

[ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

Autoconf has been updated to the latest upstream release 2.71, see the packaging notes below. Additionally the automake wrapper has been updated to the latest upstream version 15 (with some modifications for Cygwin). GNU Autoconf is an extensible package of m4 macros that produce shell scripts

[ANNOUNCEMENT] Updated: autoconf-archive-2021.02.19-1

Autoconf Archive has been updated to the latest upstream release 2021-02-19 on Cygwin. The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

Re: Autoconf files need v2.69

On 2020-11-18 11:19, Biswapriyo Nath via Cygwin wrote: I am not familiar with newlib. Please feel free whatever you want to do with my previously provided diff. Also my previous question is unanswered. Cygwin provides autoconf 2.69 but it's what builds the package that counts, also pe

Re: Autoconf files need v2.69

I am not familiar with newlib. Please feel free whatever you want to do with my previously provided diff. Also my previous question is unanswered. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.ht

Re: Autoconf files need v2.69

On Nov 18 15:06, Biswapriyo Nath via Cygwin wrote: > Currently the autoconf files in newlib-cygwin repo are in 2.64 version > but the latest autoconf package is version 2.69. So, autoreconf > command shows errors. Possible diff attached. We can update to 2.68, but not 2.69. Newlib still

Autoconf files need v2.69

Currently the autoconf files in newlib-cygwin repo are in 2.64 version but the latest autoconf package is version 2.69. So, autoreconf command shows errors. Possible diff attached. diff --git a/config/override.m4 b/config/override.m4 index 52bd1c3..1c3c298 100644 --- a/config/override.m4 +++ b

[ANNOUNCEMENT] autoconf-archive 2019.01.06-1

The following packages have been uploaded to the Cygwin distribution: * autoconf-archive-2019.01.06-1 The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

[ANNOUNCEMENT] autoconf-archive 2017.09.28-1

The following packages have been uploaded to the Cygwin distribution: * autoconf-archive-2017.09.28-1 The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

Re: No gawk-doc package, gawk source autoconf fails

and tried to configure enough to build doc. Seems to be problem with autoconf autopoint gettext package version - something run by autoreconf seems to be detecting gettext 0.19.8-1 as 0.19.8.1 instead of 0.19.8 which causes autopoint to fail: This is already fixed in cygport git master. Thanks

Re: No gawk-doc package, gawk source autoconf fails

nd tried to configure enough to build doc. > > Seems to be problem with autoconf autopoint gettext package version > > - something run by autoreconf seems to be detecting gettext 0.19.8-1 as > > 0.19.8.1 instead of 0.19.8 which causes autopoint to fail: > > This is alrea

Re: No gawk-doc package, gawk source autoconf fails

On 2016-11-09 18:02, Brian Inglis wrote: Looked for gawk doc in /usr/share/doc/gawk*/ - no HTML, PDF etc. Checked for gawk doc as a package - no gawk-doc or anything like it. Downloaded gawk package source and tried to configure enough to build doc. Seems to be problem with autoconf autopoint

No gawk-doc package, gawk source autoconf fails

Looked for gawk doc in /usr/share/doc/gawk*/ - no HTML, PDF etc. Checked for gawk doc as a package - no gawk-doc or anything like it. Downloaded gawk package source and tried to configure enough to build doc. Seems to be problem with autoconf autopoint gettext package version - something run by

Re: Autoconf fooled by AC_FC_LINE_LENGTH

. This is not mentioned in the autoconf manual I'm looking at. I don't know if the source code comment or the manual is correct (it's been 20 years since I last used fortran...) Hi Peter, thanks for the hint, unfortunately it makes no difference. Looking at the upstream cod

Re: Autoconf fooled by AC_FC_LINE_LENGTH

(unlimited) before the usual LT_PREREQ([2.4.2]) LT_INIT([win32-dll]) is causing the libtool to be incorrectly set, versus the right case It seems libtool is incorrectly set for MSVC platform I tried to move the libtool inizialization before the AC_FC_LINE_LENGTH but autoconf is objecting on wrong

Re: Autoconf fooled by AC_FC_LINE_LENGTH

$libname | sed -e s/^lib/cyg/``echo \$release | > \$SED -e s/[.]/-/g`\$versuffix\$shared_ext" > +soname_spec="" > - > > It seems libtool is incorrectly set for MSVC platform > > I tried to move the libtool inizialization before

Autoconf fooled by AC_FC_LINE_LENGTH

y set for MSVC platform I tried to move the libtool inizialization before the AC_FC_LINE_LENGTH but autoconf is objecting on wrong preference. It seems a bug impacting only cygwin. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cyg

[ANNOUNCEMENT] autoconf-archive 2016.03.20-1

The following packages have been uploaded to the Cygwin distribution: * autoconf-archive-2016.03.20-1 The GNU Autoconf Archive is a collection of more than 450 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet

[ANNOUNCEMENT] New: autoconf-archive-2014.10.15-1

The following package has been added to the Cygwin distribution: * autoconf-archive-2014.10.15-1 The GNU Autoconf Archive is a collection of more than 500 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet. Every

[ANNOUNCEMENT] Updated: gcc-tools-epoch2-autoconf-2.64-2

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x

[ANNOUNCEMENT] Updated: gcc-tools-epoch1-autoconf-2.59-2

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x

Re: passing -no-undefined to libtool with autoconf/automake

On 2013-07-21 03:43, marco atzeri wrote: As latest gcc's are not ignoring anymore "-no-undefined" and the configure halt with error if LDFLAGS="-no-undefined" is defined in advance Right, as gcc no longer ignores arguments it doesn't accept. I am currently building packages adding almost at t

passing -no-undefined to libtool with autoconf/automake

Hi All, As latest gcc's are not ignoring anymore "-no-undefined" and the configure halt with error if LDFLAGS="-no-undefined" is defined in advance *** Startup tests checking build system type... i686-pc-cygwin checking host system type... i686-pc-cyg

[ANNOUNCEMENT] Updated: autoconf-13-1

The autoconf package has been updated to version 13. Recall that this package is not the real autoconf, but is a wrapper system to delegate to the appropriate version of real autoconf (either 2.13 or 2.69 at present). This is a feature enhancement and compatibility update, which adds support for

Re: autoconf 2.69 ?

On 10/14/2012 7:07 PM, marco atzeri wrote: Charles, any chance of upgrading Autoconf to last version from current 2.68 ? I start to see packages with AC_PREREQ(2.69) Regards Marco ping GraphicsMagick-1.3.17 needs it. Marco -- Problem reports: http://cygwin.com/problems.html

autoconf 2.69 ?

Charles, any chance of upgrading Autoconf to last version from current 2.68 ? I start to see packages with AC_PREREQ(2.69) Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html

Re: autoconf packaging error

On 11/15/2011 5:06 AM, Csaba Raduly wrote: Hi all, There seems to be a packaging error in autoconf (autoconf2.5-2.68-1 according to cygcheck -f /usr/share/man/man1/autoconf-2.68.1.gz). The shorter names for the man pages point to non-existent files: The symlinks don't appear in the outp

autoconf packaging error

Hi all, There seems to be a packaging error in autoconf (autoconf2.5-2.68-1 according to cygcheck -f /usr/share/man/man1/autoconf-2.68.1.gz). The shorter names for the man pages point to non-existent files: ~/workspace/TTCNv3 $ file /usr/share/man/man1/auto* /usr/share/man/man1/autoconf-2.68.1

Re: Broken autoconf mmap test

the mapped > region that correspond to > added or removed portions of the file is unspecified. That has nothing to do with what the autoconf test tests. Consider a filesize of 1 bytes and a pagesize of 4K. Since mmap always returns full pages, the file is mapped into a single 4K page. The a

Re: Broken autoconf mmap test

d. > > Unless the right thing to do in autoconf is to separate the test into > two levels; one of whether most mmap works but you can't extend files > (cygwin always passes) and one whether writing beyond EOF works as > required by POSIX (cygwin currently fails on W64, but hop

Re: Broken autoconf mmap test

f there are applications out there which rely on this >> crude behaviour. > > It doesn't look like there's going to be an autoconf change to resolve > this: > > http://lists.gnu.org/archive/html/autoconf/2011-03/msg00041.html Unless the right thing to do in aut

Re: Broken autoconf mmap test

E and allows to specify a view which is bigger than the filesize. I tried this on W7-64, and it works. Just not exactly as we need it. The trailing pages are not commited but only reserved, so accessing them still results in a SEGV. And while commiting them allows to run the autoconf testcase, it

Re: Broken autoconf mmap test

ify a view which is bigger than > >the filesize. I tried this on W7-64, and it works. Just not exactly > >as we need it. The trailing pages are not commited but only reserved, > >so accessing them still results in a SEGV. And while commiting them > >allows to run the

Re: Broken autoconf mmap test

ng to do with Windows 7. Actually, the autoconf mmap test is testing a scenario which does not work on 64 bit Windows systems. Here's what happens in a nutshell. The actual pagesize on Windows is 4K. But there's something called "allocation granularity" which is 64K. If you

Re: Broken autoconf mmap test

nothing to do with Windows 7. Actually, the > >autoconf mmap test is testing a scenario which does not work on 64 bit > >Windows systems. Here's what happens in a nutshell. > > > >The actual pagesize on Windows is 4K. But there's something called > >&quo

Re: Broken autoconf mmap test

On 3/23/2011 5:19 AM, Corinna Vinschen wrote: On Mar 22 17:53, Ken Brown wrote: On 3/22/2011 4:59 PM, Eric Blake wrote: On 03/20/2011 02:51 PM, Ken Brown wrote: What's the status of the broken autoconf mmap test, which always fails on Cygwin even though Cygwin has a working mmap? Aut

Re: Broken autoconf mmap test

On Mar 22 17:53, Ken Brown wrote: > On 3/22/2011 4:59 PM, Eric Blake wrote: > >On 03/20/2011 02:51 PM, Ken Brown wrote: > >>What's the status of the broken autoconf mmap test, which always fails > >>on Cygwin even though Cygwin has a working mmap? > > > >

Re: Cygwin fails autoconf mmap test under Win 7 (was: Broken autoconf mmap test)

On 3/22/2011 5:53 PM, Ken Brown wrote: On 3/22/2011 4:59 PM, Eric Blake wrote: On 03/20/2011 02:51 PM, Ken Brown wrote: What's the status of the broken autoconf mmap test, which always fails on Cygwin even though Cygwin has a working mmap? Autoconf 2.65 and newer do not have the bug.

Re: Broken autoconf mmap test

On 3/22/2011 4:59 PM, Eric Blake wrote: On 03/20/2011 02:51 PM, Ken Brown wrote: What's the status of the broken autoconf mmap test, which always fails on Cygwin even though Cygwin has a working mmap? Autoconf 2.65 and newer do not have the bug. But packages still exist where configur

Re: Broken autoconf mmap test

On 03/20/2011 02:51 PM, Ken Brown wrote: > What's the status of the broken autoconf mmap test, which always fails > on Cygwin even though Cygwin has a working mmap? Autoconf 2.65 and newer do not have the bug. But packages still exist where configure was generated with < 2.65, so

Broken autoconf mmap test

What's the status of the broken autoconf mmap test, which always fails on Cygwin even though Cygwin has a working mmap? The last message I can find on the cygwin list is from November 2009: http://cygwin.com/ml/cygwin/2009-11/msg00368.html Was this ever resolved? I see that cygpo

[ANNOUNCEMENT] Updated: autoconf-10-1

The autoconf package has been updated to version 10. Recall that this package is not the real autoconf, but is a wrapper system to delegate to the appropriate version of real autoconf (either 2.13 or 2.68 at present). This is a feature enhancement and compatibility update, which adds support for

[ANNOUNCEMENT] Updated: autoconf-9-1

The autoconf package has been updated to version 9. Recall that this package is not the real autoconf, but is a wrapper system to delegate to the appropriate version of real autoconf (either 2.13 or 2.67 at present). This is a feature enhancement and compatibility update, which adds support for

Re: Autoconf 2.1 / 2.5

On 2010-03-29 23:28, NightStrike wrote: Autoconf is listed twice in the list of installable packages from cygwin, and described thusly: autoconf2.1 - Stable version, latest = 2.13-10 autoconf2.5 - Development version, latest =2.65-1 Think it's about time that these are labeled differ

Autoconf 2.1 / 2.5

Autoconf is listed twice in the list of installable packages from cygwin, and described thusly: autoconf2.1 - Stable version, latest = 2.13-10 autoconf2.5 - Development version, latest =2.65-1 Think it's about time that these are labeled differently? 2.65 is hardly a development version

[ANNOUNCEMENT] New: gcc-tools-epoch2-autoconf-2.64-1

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x

[ANNOUNCEMENT] New: gcc-tools-epoch1-autoconf-2.59-1

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x

[ANNOUNCEMENT] Updated: gcc-tools-autoconf-2.59-11

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x

Re: Problem with autoconf autodepend

On 11/22/2009 10:39 PM, Dave Korn wrote: Ken Brown wrote: I guess so. I wonder if there's a timing problem so that the deps directory isn't being created before it needs to be used. But here's something very strange: Angelo Graziosi, who is also playing with this, told me that he *doesn't* g

Re: Problem with autoconf autodepend

Ken Brown wrote: > I guess so. I wonder if there's a timing problem so that the deps > directory isn't being created before it needs to be used. But here's > something very strange: Angelo Graziosi, who is also playing with this, > told me that he *doesn't* get error if he does 'make -j4', but

Re: Problem with autoconf autodepend

On 11/22/2009 6:34 PM, Dave Korn wrote: Ken Brown wrote: And here's the build failure: gcc -c -Demacs -DHAVE_CONFIG_H -I. -I/tmp/emacs/src -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/

Re: Problem with autoconf autodepend

Ken Brown wrote: > And here's the build failure: > > gcc -c -Demacs -DHAVE_CONFIG_H -I. -I/tmp/emacs/src > -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include

Problem with autoconf autodepend

eport this in case it indicates a cygwin problem and/or an autoconf problem. Of course, I'd also like to know if it's an emacs problem so I can report it to them. Here's the relevant excerpt from configure.in: if test $HAVE_GNU_MAKE = yes; then AC_MSG_CHECKING([whether

Re: autoconf/configure problem on text mounts

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew on 11/22/2009 9:06 AM: > cd HandBrake > ./configure --launch-jobs=1 --launch --gcc=/usr/bin/gcc-4.exe Where does --launch come from? That's not a typical argument in configure scripts generated by Autoconf, no

Re: autoconf/configure problem on text mounts

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew on 11/22/2009 9:06 AM: > Cygwin 1.5.25-15, autoconf 2.64, HandBrake svn 2953, lame 3.98, and gcc 4.3.2 > > > It appears it is still happening. It appears WHAT is still happening? You left out some important c

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

d. The chance that the address of data2 is not usable for mmap on > > Windows/Cygwin is 100%. > > But in testing this further, I discovered that you CAN do: > > data2 = mmap(...); > munmap (data2,...); > mmap (data2, ... MAP_FIXED) > > and get success on cygwin.

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [please limit replies about the patch itself to autoconf-patches] According to Corinna Vinschen on 11/9/2009 7:05 AM: > This part of the testcase > > data2 = (char *) malloc (2 * pagesize); > if (!data2) > return 1; >

Re: Broken autoconf mmap test

Corinna Vinschen wrote: > I had hoped that you, as the autoconf maintainer, would put this > upstream... Well, I would have done so...but you guys beat me to it. I go off-net for a day or so, and lookit what happens...I think I need to go off-net more often! -- Chuck -- Problem r

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

urther, I discovered that you CAN do: data2 = mmap(...); munmap (data2,...); mmap (data2, ... MAP_FIXED) and get success on cygwin. So I will be updating autoconf accordingly, based on the STD below. Unfortunately, it looks like I also found a hole in cygwin. Consider this (borrowing hea

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

> this option is discouraged. > > It's an upstream issue now ;) > > The problem is that I need some more advice from the cygwin list on how > best to fix the test to pass on cygwin by default. I'm hoping to release > autoconf 2.65 this week, so a speedy fix to hel

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/9/2009 4:59 AM: >>> I just found that the latest autoconf *still* has this broken test >>> for mmap, which basically calls >>> >>> data2 = malloc (size); >>> mmap

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

oesn't > >> work on Windows. An autoconf run with a newer version of autoconf would > >> be nice. > > > > I just found that the latest autoconf *still* has this broken test > > for mmap, which basically calls > > > > data2 = malloc (size); >

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

Corinna Vinschen wrote: > On Nov 8 14:56, Corinna Vinschen wrote: >> Btw., the check for mmap in grep's configure file is broken. It tries >> to mmap to a fixed address formerly allocated via malloc(). This doesn't >> work on Windows. An autoconf run with a

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

loc(). This doesn't >>> work on Windows. An autoconf run with a newer version of autoconf would >>> be nice. >> >> I just found that the latest autoconf *still* has this broken test >> for mmap, which basically calls >> >> data2 = malloc (

Re: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

Corinna Vinschen wrote: On Nov 8 14:56, Corinna Vinschen wrote: Btw., the check for mmap in grep's configure file is broken. It tries to mmap to a fixed address formerly allocated via malloc(). This doesn't work on Windows. An autoconf run with a newer version of autoconf would be

Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)

On Nov 8 14:56, Corinna Vinschen wrote: > Btw., the check for mmap in grep's configure file is broken. It tries > to mmap to a fixed address formerly allocated via malloc(). This doesn't > work on Windows. An autoconf run with a newer version of autoconf would > be nice.

[ANNOUNCEMENT] Updated: autoconf-7-1

The autoconf package has been updated to version 7. Recall that this package is not the real autoconf, but is a wrapper system to delegate to the appropriate version of real autoconf (either 2.13 or 2.64 at present). This is a feature enhancement and compatibility update, which adds support for

[ANNOUNCEMENT] [1.7] Updated: autoconf-7-10

The autoconf package has been updated to version 7. Recall that this package is not the real autoconf, but is a wrapper system to delegate to the appropriate version of real autoconf (either 2.13 or 2.64 at present). This is a feature enhancement and compatibility update, which adds support for

autoconf info packaging [Was: Re: "requires" line for cygwin; bug in upset?]

Dave Korn wrote: > I also lost a bunch of my info page indexing after the last update, but I > haven't looked into what's going on yet. I'm just sure that "info autoconf" > used to work and now I have to type "info autoconf2.63". Well, the autoconf

Re: gcc-tools versions of autotools [Fwd: Moving to Autoconf 2.64, Automake 1.11]

Charles Wilson wrote: > /not/ update them at all; > 1) The current and soon-to-be-released gcc's, based on gcc-3.4.5 and > gcc-4.3.x, both still require autoconf-2.59 and automake-1.9.6 Good reasoning. > So, as soon as I spin the "regular" cygwin autoconf-2.64 pa

gcc-tools versions of autotools [Fwd: Moving to Autoconf 2.64, Automake 1.11]

(Mostly for Dave Korn, but other opinions solicited): How do you want me to handle updating gcc-tools-autoconf and gcc-tools-automake? My preference would be to /not/ update them at all; at least, not for a while. Reasons: 1) The current and soon-to-be-released gcc's, based on gcc-3.4.

Re: managing autoconf versions?

the version macros search $PATH? >>Or do all the tools append versions to all their directories/files? >> >> >>You know, ideally..ideally what I would do is >>download "every" version of autoconf/automake >>configure and install them al

Re: managing autoconf versions?

son, flex, ...) are included, I ask the sender to send a new copy without these files. There are really a pain in the ass! They are not worth the time it takes me to remove the patches. > - It is important to match versions for testing purposes. > If I test with a non match

Re: managing autoconf versions?

Jay wrote: > This is a little off topic. > > How do people manage autoconf/automake versions? > GCC/binutils require specialised versions, and I keep them in a separate prefix, thanks to Chuck's gcc-tools-* packages, and add them to the front of $PATH when needed. For all

Re: managing autoconf versions?

Hello Jay, * On Sat, May 16, 2009 at 06:00:30AM + Jay wrote: > How do people manage autoconf/automake versions? [...] > Rather I'm wondering about submitting patches to other projects, Just make sure you do not include generated files in your patch, and you should be fine.

managing autoconf versions?

This is a little off topic. How do people manage autoconf/automake versions? In particular, I'm not doing "my own work" -- I could probably just install one recent version of everything and be ok. Rather I'm wondering about submitting patches to other projects, some

[ANNOUNCEMENT] New for cygwin-1.7: gcc-tools-autoconf-2.59-10

This is an unmodified version of autoconf-2.59, installed into /opt/gcc-tools/ for the use of gcc developers. Gcc requires an unpatched, pristine version of autoconf when preparing patches for official submission. For various reasons [1] it cannot coexist with the existing autoconf packages in

[ANNOUNCEMENT] New: gcc-tools-autoconf-2.59-2

This is an unmodified version of autoconf-2.59, installed into /opt/gcc-tools/ for the use of gcc developers. Gcc requires an unpatched, pristine version of autoconf when preparing patches for official submission. For various reasons [1] it cannot coexist with the existing autoconf packages in

Re: [ITP] gcc-tools-autoconf, gcc-tools-automake

Oops, misdirected, that should have gone to the -apps list. Sorry all! DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com

Re: [ITP] gcc-tools-autoconf, gcc-tools-automake

Charles Wilson wrote: > http://cygwin.cwilson.fastmail.fm/ITP/gcc-tools-autoconf-2.59-2-src.tar.bz2 > http://cygwin.cwilson.fastmail.fm/ITP/gcc-tools-autoconf-2.59-2.tar.bz2 > http://cygwin.cwilson.fastmail.fm/ITP/gcc-tools-autoconf.hint > > sdesc: "(gcc-special) automa

Re: [ITP] gcc-tools-autoconf, gcc-tools-automake

Charles Wilson wrote: > Special versions of "pristine" (that is, no cygwin-special patches) of > autoconf-2.59 and automake-1.9.6 as required by gcc, installed into > /opt/gcc-tools/{bin|lib|share}. sorry. wrong list. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/

[ITP] gcc-tools-autoconf, gcc-tools-automake

Special versions of "pristine" (that is, no cygwin-special patches) of autoconf-2.59 and automake-1.9.6 as required by gcc, installed into /opt/gcc-tools/{bin|lib|share}. This should make it easier for Dave, and those who want to help him, to develop gcc and binutils -- avoiding things

Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

On Tue, Dec 09, 2008 at 06:25:48PM +, Dave Korn wrote: >On 12/9/08, Dave Korn wrote: >>Hi gang (and Chuck in particular!) > >Eeeww. Did all those attachments come out inline? They looked like regular old attachments here to me. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe

Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

Charles Wilson wrote: > and thus make it easier to move officially to 2.6x at some point in the > future, are still in work. BTW, Ralf expressed a tentative plan to work on this after 4.4 has branched and mainline returns to stage 1: . Brian -- U

Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

y box: gcc-autoconf and gcc-automake [*], which: (1) are pristine versions of ac-2.59 and am-1.9.6 with no cygwin-specific code changes (2) install into /opt/gcc-tools/{bin|share} (3) /opt/gcc-tools/share/aclocal-1.9/dirlist specifies /usr/share/aclocal/ so as to "find" .m4 files fr

Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

Eric Blake wrote: > Oops. m4_append was undocumented in 2.60, then changed semantics in autoconf > 2.62. Newer libtool works around the semantic change by using lt_append, not > m4_append: > http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=5b560bd > > But

Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

efn([lt_decl_varnames])[, ], [, ][]m4_re_escape ([macro_version])[, ], > [], > [m4_append([lt_decl_varnames], [macro_version], [[, ]]) Oops. m4_append was undocumented in 2.60, then changed semantics in autoconf 2.62. Newer libtool works around the semantic change by using l

  1   2   3   >