autoupdate fails: undefined macro: m4_PACKAGE_VERSION

Running autoupdate on a clone of this repository https://github.com/wyatt8740/x48 results in this error: ~/x48$ autoupdate -d autoupdate:1605289: working in /tmp/aufraZ4c /usr/share/autoconf/autoconf/general.m4:327: error: m4_defn: undefined macro: m4_PACKAGE_VERSION /usr/share/autoconf/autocon

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

Follow-up Comment #2, sr#110612 (group autoconf): No problem. If I create, $ cat configure #!/bin/sh echo $0 in my home directory, then at least in bash and dash, the $PATH entry gets prepended to $0 when it is needed to resolve "configure": $ PATH=/home/mjo configure /home/mjo/configure $ PA

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

URL: Summary: Re-exec of $as_myself chooses wrong configure script from PATH Project: Autoconf Submitted by: mjo Submitted on: Sat 19 Feb 2022 01:07:39 AM UTC Category: None

realpath fails on MacOS 11.1 (big sur), with bugfix

realpath() is failing to compile for me on MacOS 11.1 on an Apple M1 Mac. I encountered this when building GNU Global Tags from the most recent source archive at global-6.6.5.tar.gz . This is due to an error because realpath cannot be found. The

Potential bug in AC_CONFIG_SRCDIR

R/src/dockcontrollermsg.c]) AC_CONFIG_SRCDIR([$DCMSGSRCDIR/include/dockcontrollermsg.h]) … Thank you, Michael Cress --

Re: bug#20733: coreutils build problem

uot; is not allowed. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. On Fri, Jun 5, 2015 at 4:24 PM, Paul Eggert wrote: > Michael Felt wrote: &

Re: bug#20733: coreutils build problem

I did not run config.status - this dog missed that part of the trick! On Fri, Jun 5, 2015 at 4:30 PM, Eric Blake wrote: > On 06/05/2015 08:09 AM, Michael Felt wrote: > > root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1 > > rm -f src/coreutils.h > >

Re: bug#20733: coreutils build problem

quot;, $main)"; done | sort > src/coreutils.ht /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. make: 1254-004 The error code from the last command is 2. Stop. root@x065:[/data/prj/gnu/coreutils/coreutils-8.23] On Fri, Jun 5, 2015 at 4:07 PM, Paul Eggert wr

Re: bug#20733: coreutils build problem

As I said before - I do not really know the ins and outs of autoconf and automake - so I shall only summarize my steps: On my "download" server... (/data/prj is an NFS mount shared by all servers) michael@x071:[/data/prj/gnu/coreutils]xz -dc *23*xz | tar xf - michael@x071:[/da

Re: bug#20733: coreutils build problem

error code from the last command is 2. Shall rerun ./configure and see if the ./src directory problem is solved as well (after automake) p.s. I do this packaging as root - so I always need to # export FORCE_UNSAFE_CONFIGURE=1 Would be "more friendly" if this check could be reported ea

Re: bug#20733: coreutils build problem

ncerned - I had automake 1.15 installed. I removed it and installed automake-1.14.1 and the 'complaint' went away when I ran automake. On Fri, Jun 5, 2015 at 3:08 PM, Eric Blake wrote: > On 06/05/2015 05:13 AM, Michael Felt wrote: > > I think I still have automake 1.14 lying around,

Re: bug#20733: coreutils build problem

After rerunning ./configure --prefix=/opt I still stop at: GEN src/coreutils.h /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. make: 1254-004 The error code from the last command is 2. On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt wrote: > I think I still have

Re: bug#20733: coreutils build problem

different executable (different inode) michael@x071:[/usr/bin]ls -li *ksh* 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93 On Fri, Jun 5, 2015 a

Re: bug#20733: coreutils build problem

, unpack, patch, automake, and see where/how things go). Michael On Fri, Jun 5, 2015 at 1:16 PM, Michael Felt wrote: > After rerunning ./configure --prefix=/opt I still stop at: > > GEN src/coreutils.h > /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. > make

Re: bug#20733: coreutils build problem

ing!! On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake wrote: > [adding autoconf] > > On 06/04/2015 01:17 PM, Paul Eggert wrote: > > > > On 06/04/2015 09:41 AM, Michael Felt wrote: > >> GEN src/coreutils.h > >> /bin/sh: 0403-057 Syntax error at line 1 : `;

Re: bug#20733: coreutils build problem

This is reassuring. Thank you for the reply. On Fri, Jun 5, 2015 at 3:05 PM, Eric Blake wrote: > On 06/05/2015 04:45 AM, Michael Felt wrote: > > [we tend to avoid top-posting on technical lists, as it makes it harder > to follow the flow of the message] > > > My "

Re: configure checking for csh hash hack

Paul Eggert cs.ucla.edu> writes: > > Goldberg, Jon (Jon) wrote: > > When used in the context of groff-1.22, the script does the following: > > > > if echo ./conftest.sh | (csh >/dev/null 2>&1) >/dev/null 2>&1; > > That's not from autoconf; it's something groff itself does, so please repor

[GNU Autoconf 2.69] testsuite: 137 207 224 failed

## - ## ## Test results. ## ## - ## ERROR: 456 tests were run, 7 failed (4 expected failures). 47 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information yo

Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc >= 4.5

On Thu, Apr 26, 2012 at 09:15:09AM +0200, Michael Olbrich wrote: > On Wed, Apr 25, 2012 at 10:34:18AM -0600, Eric Blake wrote: > > On 04/25/2012 02:56 AM, Michael Olbrich wrote: > > > when cross-compiling with gcc >= 4.5 (I think), AC_CHECK_ALIGNOF fails to > > > dete

Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc >= 4.5

On Wed, Apr 25, 2012 at 10:34:18AM -0600, Eric Blake wrote: > On 04/25/2012 02:56 AM, Michael Olbrich wrote: > > when cross-compiling with gcc >= 4.5 (I think), AC_CHECK_ALIGNOF fails to > > detect the alignment. This happens because the compiler fails with "error: > >

AC_CHECK_ALIGNOF fails when cross-compiling with gcc >= 4.5

ot quite sure when __builtin_offsetof should be used, but it is used in the Linux kernel for gcc 4.x, so I think this is correct. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/

problem with automake and bison

I am using the autotools in combination with GNU Bison and Flex. In particular I am using the %glr directive in my bison file (parse.y). Everything works fine, except that when I run 'make', 'ylwrap' is invoked which runs 'bison -y -d' on 'parse.y' producing 'y.tab.h' and 'y.tab.c'. 'ylwrap' then r

Fw: Re: compiling groff under uwin using mingw and bash

he current make run. I executed make in the same directory as configure, /c/groff. Mike 090401.1627 --- On Tue, 3/31/09, michael lindenmeyer wrote: However, there appears to be a problem with a /tmp directory that  I don't understand. make.log.gz Description: GNU Zip compressed data

Re: compiling groff under uwin using mingw and bash

Ralf: I decided that the Borland and visual C software was just not working, so went back to mingw, and executed configure under using 4 different combinations of shell and sed, ksh and bash, mingw sed and uwin sed. It turned out that the only configures that completed with exit 0 were the two r

compiling groff under uwin using borland compilers

I created an environment for compiling via Borland 5.5, and verified that I can compile simple c source programs with this configuration.     Specified by UWIN: PACKAGE_cc=/c/borland/bcc55/bin/   Identify the compilers and the preprocessor: cc=/c/borland/bcc55/bin/bcc32.exe c++=/c/borland/bcc55

RE: Autoconf manual's coverage of signed integer overflow & portability

> -Original Message- > I would like to say the one thing I have not heard through this > discussion is the real reason why the C standards comittee decided > signed overflow as being undefined. All I can think of is they were > thinking of target that do saturation for plus/minus but wrapp

dlfcn.h error on solaris 10,x86, sunstudio 10

I get the following error building packages in pkgsrc on my solaris 10 installation using sunstudio 10. Output follows: == checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the prepr

Re: Possible bug - AC_PROG_CC

Thanx, I appreciate the quick replay. I'll make a workaround for this in the application. Regards /Michael On 12/7/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: Hello Michael, * Michael Ambrus wrote on Thu, Dec 07, 2006 at 05:18:05PM CET: > It seems that AC_PROG_CC misbehaves

Possible bug - AC_PROG_CC

to set this to 2.13 I get all sorts of other errors. Setting it to 2.50 produces the same as mentioned above. 'autoconf -V' will respond 2.50 however... Regards /Michael

bug - alpha server - Tru64 5.1B patch kit 4

configure: WARNING: netinet/if_ether.h: present but cannot be compiled configure: WARNING: netinet/if_ether.h: check for missing prerequisite headers? configure: WARNING: netinet/if_ether.h: proceeding with the preprocessor's resul t configure: WARNING: ## #

Re: bug report by request of MAC OS 10.3.8

thanks! On Fri, 11 Mar 2005 11:36:35 +0100, Stepan Kasal <[EMAIL PROTECTED]> wrote: > Hello, > > On Thu, Mar 10, 2005 at 07:09:21PM -0700, Michael Menke wrote: > > checking appkit/appkit.h usability... no > > checking appkit/appkit.h presence... yes > > co

bug report by request of MAC OS 10.3.8

x27;s result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for appkit/appkit.h... yes checking appkit.h usability... no -- Michael

bug report

Encountered while compiling Bash 3.0 on SunOS 4.1.4. I'm reporting it as requested. checking sys/resource.h usability... no checking sys/resource.h presence... yes configure: WARNING: sys/resource.h: present but cannot be compiled configure: WARNING: sys/resource.h: check for missing prerequisit