Re: autoconfiscating getopt_long()...
"Matthew" == Matthew Whitworth [EMAIL PROTECTED] writes: Matthew What I have done so far (and it seems to work), is to Matthew copy getopt.c and getopt.h to getopt_long.c and Matthew getopt_long.h, and then to use the following snippets: Matthew configure.in: Matthew AC_REPLACE_FUNCS(getopt_long) Does someone here handle the FreeBSD case in some way? What about: AC_CHECK_FUNCS([getopt_long],, [#FreeBSD has a gnugetopt library for this: AC_CHECK_LIB([gnugetopt],[getopt_long], [AC_DEFINE([HAVE_GETOPT_LONG])], [# use the gnu replacement AC_LIBOBJ(getopt) AC_LIBOBJ(getopt1)])]) Matthew Makefile.am: Matthew useless_SOURCES=useless.c getopt_long.h tailor.h Matthew dnl This condionally links getopt_long.o Matthew useless_LDADD=@LIBOBJS@ Matthew useless.c: Matthew #ifndef HAVE_GETOPT_LONG Matthew # include "getopt_long.h" Matthew #else Matthew # include getopt.h Matthew #endif Matthew I have no idea what tailor.h does yet, but getopt.h Matthew #includes it. I don't see any use of getopt.h in the version of getopt I use. [...] PS: http://sources.redhat.com/ml/automake/2000-09/msg00036.html -- Alexandre Duret-Lutz
Re: FYI: `Document' qnx (Was: Various systems)
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes: Pavel I'm worried about the political side of the problem. Once QNX Pavel is there other people will want to put other OS'es into the Pavel manual. That's definitely my wish! Pavel The problem is that the documentation for programs, especially Pavel for commercial programs tends not to mention the existing Pavel problems, at least from the point of view of an Autoconf Pavel developer, i.e. I don't expect to see the description of the Pavel shell bugs on the HP-UX site. Yes, I agree. This is not exactly the point. What I want, is some form of small database on what you might be willing to know when your start working on portability. For instance, I'd like to list all the OSes we know, and their release dates. Pavel Notably, the problem with the error status after foo=`bar` is Pavel not described in the sh documentation on the QNX site. They might not even not know it. Pavel I mean, you cannot document everything. The world Pavel changes. Restrict yourself to the relevant facts. "Hundreds Pavel processors" are not relevant and sound like advertizing. And I Pavel sound like RMS :-) Yeah, I agree my text is not too good. The thing is I'm not a user, and I heavily inspired myself from the QNX site itself. I'd prefer that some user, such as Daniele, do it, but an impetus is needed, and I meant to make it. I very much agree the real content is and will be there. There must be listed and classified the failures we know, and certainly not in Shellology nor Systemology. Pavel Ok. If you insist on having the Systemology section I'll try to Pavel put more relevant content there. I'm updating my .plan I insist on the fact that I understand your point. I still want to do something like this because I think some people might be interested in such things. For instance, do you know since when large file support is in SunOS? There are questions like this that I'd like to see answered somewhere. And then, naturally, I believe the Autoconf documentation is a good place for this.
Re: FYI: `Document' qnx (Was: Various systems)
Akim, If you allow me a word as a complete outsider, I personally think that your wish to maintain documentation for every OS is extremely nice and denotes a lot of courage, because maintaining such a thing can be hell. I think this is Pavel's point: that this effort can fade in time, and we would just have an obsolete documentation about old OSs. And maybe the autoconf documentation isn't really the right place where people would look for it; for my part, I would love for example to have a website where there is a DB of the various OSs with their characteristics, portability issues, etc. Does anyone know if there is such a thing? If there is not, would there be a valorous volunteer that would set it up?:) Just my 0.02Euro. Cheers, Daniele. On 6 Dec 2000, Akim Demaille wrote: "Pavel" == Pavel Roskin [EMAIL PROTECTED] writes: Pavel I'm worried about the political side of the problem. Once QNX Pavel is there other people will want to put other OS'es into the Pavel manual. That's definitely my wish! Pavel The problem is that the documentation for programs, especially Pavel for commercial programs tends not to mention the existing Pavel problems, at least from the point of view of an Autoconf Pavel developer, i.e. I don't expect to see the description of the Pavel shell bugs on the HP-UX site. Yes, I agree. This is not exactly the point. What I want, is some form of small database on what you might be willing to know when your start working on portability. For instance, I'd like to list all the OSes we know, and their release dates. Pavel Notably, the problem with the error status after foo=`bar` is Pavel not described in the sh documentation on the QNX site. They might not even not know it. Pavel I mean, you cannot document everything. The world Pavel changes. Restrict yourself to the relevant facts. "Hundreds Pavel processors" are not relevant and sound like advertizing. And I Pavel sound like RMS :-) Yeah, I agree my text is not too good. The thing is I'm not a user, and I heavily inspired myself from the QNX site itself. I'd prefer that some user, such as Daniele, do it, but an impetus is needed, and I meant to make it. I very much agree the real content is and will be there. There must be listed and classified the failures we know, and certainly not in Shellology nor Systemology. Pavel Ok. If you insist on having the Systemology section I'll try to Pavel put more relevant content there. I'm updating my .plan I insist on the fact that I understand your point. I still want to do something like this because I think some people might be interested in such things. For instance, do you know since when large file support is in SunOS? There are questions like this that I'd like to see answered somewhere. And then, naturally, I believe the Autoconf documentation is a good place for this.
Re: Shell crash on SunOS 4.1.3
"Torbjorn" == Torbjorn Granlund [EMAIL PROTECTED] writes: Torbjorn Running configure from the current GMP working sources, Torbjorn SunOS 4.1.3 /bin/sh catches a segfault. Thanks a lot. I'm working on it, which means I first try to get this *(*£$ test suite work properly on SunOS. I don't think there is a test which exercises the bug, afaics. Could I ask you to write a dummy configure.in which triggers the bug on your system? Thanks in advance!
Re: OpenBSD 2.7
Hello, Akim! | Now we have this in the top-level Makefile.am: | | # Follow the version number changes. | $(bin_SCRIPTS): configure.in | | When BSD make scans for rules to make autoconf it picks the explicit rule | first, but it's empty. I believe that there is no way to use the suffix | rule in BSD make if an explicit rule is present. I just observed the same failure from SunOS' stock make. So let's remove the explicit rule. It's only helpful to maintainers, but they are supposed to clean up the working directory from time to time. Another solution would be AM_MAINTAINER_MODE in configure.in and @MAINT@ before the explicit rule, but I believe it's an overkill. Regards, Pavel Roskin
config.guess Linux overhaul
It's that time again. The config.guess script is losing on GNU/Linux and this time, I'm going to fix it. Background: on many GNU/Linux systems, config.guess uses the output of `ld --help' to determine which architecture, object file format and C library version the build system uses. The script loses because it assumes that the primary configuration will appear first in the `supported emulations:' printed by ld(1). This is flawed because a) this is not a meaningful constraint and b) some distributions, such as Caldera OpenLinux, provide a linker that has support for linking in many, many environments (like coff-z8k, if that grabs you!). Instead, I am seeking to replace this cruft with a cleaner and more portable alternative. After much deliberation, the best I have come up with is to use file(1) from GNU fileutils, which is *very* likely to be present on every GNU/Linux system. The one drawback here is that it doesn't help me determine the version of libc installed on the system--and there may even be multiple versions. Which is the "primary"? The one that the current C compiler will link against? Comments, please. Ben
FYI: Egrep and test suite (Was: FYI: AS_EXIT)
Daniele, I've just killed another suspicious part of the test suite which might be responsible for a big part of the failures we observed. Would it be possible that you run it again? The ``bad'' news is that I couldn't find in your logs the error messages `egrep' should have printed. One hope though: how do you build the logs you send us? It is extremely important that you include stderr, which basically means ./testsuite testsuite.log 21 FYI, here is the patch. Index: ChangeLog from Akim Demaille [EMAIL PROTECTED] The SunOS' egrep fails to process properly the `egrep' invocations of the test suite. * tests/aclocal.m4 (AC_STATE_SAVE): If egrep fails, remove the output file. * tests/atspecific.m4 (_AT_CHECK_AC_MACRO): Don't check `state-*' if the files are not present. * m4sugar.m4 (m4_join): Rename as... (m4_smash): this. * tests/aclocal.m4 (join): Move as... * m4sugar.m4 (m4_flatten): this. * autoconf.sh (trace.m4): Rename m4_smash as m4_flatten. Index: acgeneral.m4 === RCS file: /cvs/autoconf/acgeneral.m4,v retrieving revision 1.644 diff -u -u -r1.644 acgeneral.m4 --- acgeneral.m4 2000/12/06 08:58:42 1.644 +++ acgeneral.m4 2000/12/06 14:01:52 @@ -511,7 +511,7 @@ #ive ], [-Var-])end #= -active--b--active-end m4_define([AC_FOREACH], -[m4_foreach([$1], m4_split(m4_strip(m4_join([$2]))), [$3])]) +[m4_foreach([$1], m4_split(m4_strip(m4_flatten([$2]))), [$3])]) Index: autoconf.sh === RCS file: /cvs/autoconf/autoconf.sh,v retrieving revision 1.109 diff -u -u -r1.109 autoconf.sh --- autoconf.sh 2000/12/06 10:53:58 1.109 +++ autoconf.sh 2000/12/06 14:01:53 @@ -434,7 +434,7 @@ # MODE can be: # `at' -- the elements are enclosed in brackets. # `star' -- the elements are listed as are. - # `percent' -- the elements are `smashed': spaces are singled out, + # `percent' -- the elements are `flattened': spaces are singled out, #and no new line remains. define([_at_at], [at_ifelse([$#], [1], [], @@ -442,15 +442,15 @@ [[[$2]][$1]$0([$1], at_shift(at_shift($@)))])]) define([_at_percent], [at_ifelse([$#], [1], [], -[$#], [2], [at_smash([$2])], -[at_smash([$2])[$1]$0([$1], at_shift(at_shift($@)))])]) +[$#], [2], [at_flatten([$2])], +[at_flatten([$2])[$1]$0([$1], at_shift(at_shift($@)))])]) define([_at_star], [at_ifelse([$#], [1], [], [$#], [2], [[$2]], [[$2][$1]$0([$1], at_shift(at_shift($@)))])]) - # Smash quotes its result. - define([at_smash], + # FLATTEN quotes its result. + define([at_flatten], [at_patsubst(at_patsubst(at_patsubst([[[$1]]], [\\ ]), @@ -535,7 +535,7 @@ # $*, list of unquoted effective arguments. if (arg == "*") return "]at_star([" (separator ? separator : ",") "], $@)[" -# $%, list of smashed unquoted effective arguments. +# $%, list of flattened unquoted effective arguments. if (arg == "%") return "]at_percent([" (separator ? separator : ":") "], $@)[" } Index: m4sugar.m4 === RCS file: /cvs/autoconf/m4sugar.m4,v retrieving revision 2.30 diff -u -u -r2.30 m4sugar.m4 --- m4sugar.m4 2000/12/06 08:58:42 2.30 +++ m4sugar.m4 2000/12/06 14:01:57 @@ -1333,17 +1333,17 @@ -# m4_join(STRING) +# m4_flatten(STRING) # --- # If STRING contains end of lines, replace them with spaces. If there # are backslashed end of lines, remove them. This macro is safe with # active symbols. #m4_define(active, ACTIVE) -#m4_join([active +#m4_flatten([active #act\ #ive])end #= active activeend -m4_define([m4_join], +m4_define([m4_flatten], [m4_translit(m4_patsubst([[[$1]]], [\\ ]), [ ], [ ])]) @@ -1378,6 +1378,17 @@ +# m4_join(SEP, ARG1, ARG2...) +# --- +# Produce ARG1SEPARG2...SEPARGn. +m4_defun([m4_join], +[m4_case([$#], + [1], [], + [2], [[$2]], + [[$2][$1]m4_join([$1], m4_shift(m4_shift($@)))])]) + + + # m4_append(MACRO-NAME, STRING) # - # Redefine MACRO-NAME to hold its former content plus STRING at the @@ -1484,7 +1495,7 @@ m4_if(m4_eval(m4_Cursor m4_len(m4_Prefix)), 1, [m4_define([m4_Cursor], m4_len(m4_Prefix)) m4_Prefix])[]dnl -m4_foreach_quoted([m4_Word], (m4_split(m4_strip(m4_join([$1], +m4_foreach_quoted([m4_Word], (m4_split(m4_strip(m4_flatten([$1], [m4_define([m4_Cursor], m4_eval(m4_Cursor + len(m4_Word) + 1))dnl dnl New line if too long, else insert a space unless it is the first dnl of the words. Index: tests/aclocal.m4
Re: FYI: Egrep and test suite (Was: FYI: AS_EXIT)
"Daniele" == Daniele Arena [EMAIL PROTECTED] writes: Daniele Sorry, I really can't run it right now, my schedule is *too* Daniele tight. As soon as I have some spare minutes, I'll do Daniele it. Maybe not before next week, though. Sorry.:( OK, no problems. Thanks for your efforts anyway! Daniele Hm. No, I just ran the testsuite like that, everything should Daniele be in. Strange... So maybe it's something else, I don't know. Well, the previous patch was not enough actually, I'm applying this: Index: ChangeLog from Akim Demaille [EMAIL PROTECTED] * tests/aclocal.m4 (AT_STATE_SAVE): Don't even try to preserve egrep error messages, AT_CHECK will find them. Index: tests/aclocal.m4 === RCS file: /cvs/autoconf/tests/aclocal.m4,v retrieving revision 1.9 diff -u -u -r1.9 aclocal.m4 --- tests/aclocal.m4 2000/12/06 14:05:47 1.9 +++ tests/aclocal.m4 2000/12/06 15:13:10 @@ -15,9 +15,17 @@ # - AWK|LEX|LEXLIB|LEX_OUTPUT_ROOT|LN_S|M4|RANLIB|SET_MAKE|YACC # AC_PROGs from acspecific # - _|@|.[*#?].|LINENO|OLDPWD|PIPESTATUS|RANDOM|SECONDS -# Some variables some shells use and change +# Some variables some shells use and change. +# `.[*#?].' catches `$#' etc. which are displayed like this: +# | '!'=18186 +# | '#'=0 +# | '$'=6908 # - POW_LIB # From acfunctions.m4. +# +# Some `egrep' choke on such a big regex (e.g., SunOS 4.1.3). In this +# case just don't pay attention to the env. It would be great +# to keep the error message but we can't: that would break AT_CHECK. m4_defun([AC_STATE_SAVE], [(set) 21 | egrep -v -e 'm4_join([|], @@ -33,12 +41,10 @@ [^(f77_(case|underscore))=], [^(ALLOCA|GETLOADAVG_LIBS|KMEM_GROUP|NEED_SETGID|POW_LIB)=], [^(AWK|LEX|LEXLIB|LEX_OUTPUT_ROOT|LN_S|M4|RANLIB|SET_MAKE|YACC)=], - [^(_|@|.[*#?].|LINENO|OLDPWD|PIPESTATUS|RANDOM|SECONDS)=])' | + [^(_|@|.[*#?].|LINENO|OLDPWD|PIPESTATUS|RANDOM|SECONDS)=])' 2/dev/null | # There maybe variables spread on several lines, eg IFS, remove the dead # lines. fgrep = state-env.$1 -# Some `egrep' choke on such a big regex (e.g., SunOS 4.1.3). In this -# case just don't pay attention to the env. test $? = 0 || rm -f state-env.$1 ls -1 | grep -v '^state' | sort state-ls.$1
Autoconf 2.49b
[I will post this announcement on gnu.utils.bug tomorrow, unless someone beats me. I'm waiting for the snapshot to be available to do that.] A snapshot of CVS Autoconf is available at ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.49b.tar.gz There are a few pending issues that will have to be addressed before the release, so you are encouraged not to make any release of packages depending upon this version of Autoconf. Nevertheless, please start using it for your development sources. The release will be made ``quite real soon now'' (before February?), and your testing is very important for us *now*. Of course, another way to help us consists in running the test suite, in particular if your architecture is known to be tough. Reports should be sent to [EMAIL PROTECTED] The documentation has changed too, and aims at providing all the information portabilists may want to know. But it's not finished and your help would be particularly appreciated: if you know some issues which are not in the documentation, please send the patches to [EMAIL PROTECTED] Please don't send `rough' information, the queue is already heavily loaded and we don't really have enough time to convert rough information into decent Texinfo snippets. For the Autoconf Team (Alexandre, Jim, Paul, Pavel, Tom) Akim
Re: autoconfiscating getopt_long()...
On 2000.12.06 02:04:35 -0800 Alexandre Duret-Lutz wrote: Does someone here handle the FreeBSD case in some way? What about: AC_CHECK_FUNCS([getopt_long],, [#FreeBSD has a gnugetopt library for this: AC_CHECK_LIB([gnugetopt],[getopt_long], [AC_DEFINE([HAVE_GETOPT_LONG])], [# use the gnu replacement AC_LIBOBJ(getopt) AC_LIBOBJ(getopt1)])]) This is great! That's exactly what I was looking for. I don't see any use of getopt.h in the version of getopt I use. I snagged my versions of getopt.c and getopt1.c out of the libiberty source tree in the binutils package: matthew@warsaw:~/libiberty$ grep "getopt.h" getopt*.c getopt.c:#include "getopt.h" getopt1.c:#include "getopt.h" Plus, the source file calling getopt_long() needs prototypes and all those structure definitions. I didn't see any RCS or CVS version numbers in either file, but the copyright dates go to '97. If there's a standard version for including in other projects, please let me know! PS: http://sources.redhat.com/ml/automake/2000-09/msg00036.html Thanks for including this link -- I had searched the autoconf archive pretty hard before I posted, but hadn't thought about searching the automake archive as well. Cheers! Matthew -- ~~~ matthew whitworth [EMAIL PROTECTED] Between here and there is better than either here or there!
Re: autoconfiscating getopt_long()...
On 2000.12.06 02:04:35 -0800 Alexandre Duret-Lutz wrote: PS: http://sources.redhat.com/ml/automake/2000-09/msg00036.html Okay, here's the quote to end all quotes from the follow-up to the automake URL you sent me. - From http://sources.redhat.com/ml/automake/2000-09/msg00039.html: I have never actually come across the AC_REPLACE_GNU_GETOPT macro... the files getopt.c, getopt.h and getopt1.c have their own magic to #define away the body of their own code if the compilation environment provides an implementation of its own. In short, the solution is to add the three files mentioned above to your project and compile them in unconditionally. They will take care of themselves. - I *was* missing something all along! Thanks everyone for your help! Matthew -- ~~~ matthew whitworth [EMAIL PROTECTED] Between here and there is better than either here or there!
Re: config.guess Linux overhaul
On Dec 6, 2000, Ben Elliston [EMAIL PROTECTED] wrote:
Background: on many GNU/Linux systems, config.guess uses the output of `ld
--help' to determine which architecture, object file format and C library
version the build system uses.
Instead, I am seeking to replace this cruft with a cleaner and more portable
alternative. After much deliberation, the best I have come up with is to
use file(1) from GNU fileutils, which is *very* likely to be present on
every GNU/Linux system.
Not really. Libtool has gone down that path, and I regret that
immensely. Every week or so, we get a bogus bug report about `file'
not being present or not printing what we expected it to print,
because of translations, modified magic files, etc. Please don't
propagate the same mistake to config.guess.
Can't you just rely upon `uname -m' on GNU/Linux, at least for the
architecture. WRT object file format and C library version, is there
any reason why testing for __ELF__ and __GLIBC__ isn't enough?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
