Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
It's what I've done for years. Does it get rid of the problem? I don't think so but for legacy code that is no longer being maintained, either you maintain it, or the problem exists into infinity with a hard stop when someone does maintain it. I think the battle is trying to overcome continuing the legacy method of needing to replace config.guess/config.sub within a package and allow a common (or configurable) location be used as new development takes place. The http://lists.gnu.org/archive/html/autoconf/2013-05/msg00069.html is probably what you are talking about. I like this idea too, but these two ideas are not overlapping, IMO. From that thread: Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and teach autoconf to look there if it doesn't find Even if we were able to teach in future our ./configure scripts (not autoconf — as autoreconf -vfi actually solves this even now by calling automake) to look into some configurable place using special option, the ENV VAR solution _may still co-exist_ (and should have always the highest priority). Pavel ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tuesday 21 May 2013 09:57:32 Jan Engelhardt wrote: On Tuesday 2013-05-21 07:33, Pavel Raiskup wrote: Works for me. But we [distros] do want to mandate autoreconf anyway in the general case: it is the *only* way to keep upstream honest about the much hated build system not bitrotting until it decides to blow up right when we need it for a security update. I know. But there is a lot of tarballs not able to be easily autoreconf-ed (more than 10 years old) and not having upstream.. and it needs a lot of changes downstream before autoreconf successes.. (and you need to have a quite good knowledge about auto-toolset). If upstream is dead, the distros should perhaps reevaluate whether to drop the package or de facto become upstream by a process of adoption. that's might sound great, but really doesn't line up with reality. distros are chronically understaffed and becoming defacto upstreams for every random package that goes dormant/dead and can't survive an `autoreconf` isn't viable. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Monday 20 May 2013 10:37:00 Eric Blake wrote: On 05/18/2013 05:45 AM, Paul Wise wrote: On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote: Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. My original patch didn't allow overrides, here is an updated one. I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. this might be sufficient for distro packagers (once they're in the know that they have to export these two), but that doesn't help people who download arbitrary packages and run `./configure` themselves. what if the autoconf macros grew a new option/macro so that in the very uncommon case that someone has written their own, they could explicitly declare so ? AC_CANONICAL_CUSTOM this would disable the custom search path and only respect the env vars -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Saturday 18 May 2013 07:45:54 Paul Wise wrote: On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote: Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. My original patch didn't allow overrides, here is an updated one. +AC_DEFUN([AC_CONFIG_AUX_DIR, pretty sure you're missing a closing ] there +/usr/share/gnuconfig \ if you post another revision, just delete this path. i think Gentoo is the only one that uses this, and one of the other paths will catch us. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/22/2013 10:22 AM, Mike Frysinger wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. this might be sufficient for distro packagers (once they're in the know that they have to export these two), but that doesn't help people who download arbitrary packages and run `./configure` themselves. what if the autoconf macros grew a new option/macro so that in the very uncommon case that someone has written their own, they could explicitly declare so ? AC_CANONICAL_CUSTOM this would disable the custom search path and only respect the env vars I still don't see why you are overengineering things. Make the env-var precious - then it will show up in ./configure --help output, and be preserved so that ./config.status --config will show you what it was set to at the time. If the only way to get the override is via an env-var, then there is no need for the complexity of either a baked-in path search nor a means of letting SOME packages disable the complexity of a baked-in path search. If you can argue that SOME packages will want to disable the complexity, then I can argue that we should make the default of disabled complexity be everywhere. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wednesday 22 May 2013 12:27:38 Eric Blake wrote:
On 05/22/2013 10:22 AM, Mike Frysinger wrote:
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.
this might be sufficient for distro packagers (once they're in the know
that they have to export these two), but that doesn't help people who
download arbitrary packages and run `./configure` themselves.
what if the autoconf macros grew a new option/macro so that in the very
uncommon case that someone has written their own, they could explicitly
declare so ?
AC_CANONICAL_CUSTOM
this would disable the custom search path and only respect the env vars
I still don't see why you are overengineering things. Make the env-var
precious - then it will show up in ./configure --help output, and be
preserved so that ./config.status --config will show you what it was set
to at the time. If the only way to get the override is via an env-var,
then there is no need for the complexity of either a baked-in path
search nor a means of letting SOME packages disable the complexity of a
baked-in path search. If you can argue that SOME packages will want to
disable the complexity, then I can argue that we should make the default
of disabled complexity be everywhere.
i don't have a problem throwing out support for custom config.{guess,sub}
files.
as noted elsewhere in this thread, i believe that to be an obsolete art.
my point for keeping the automatic search behavior is so that people don't
have to pour through --help output and set yet-more esoteric variables so
things just work. you're of course right that by having two variables
results in dirt simple code on the implementation side. but the end user
experience is terrible. however, adding a patch search, while is more code,
is not complicated, and both the end user and distros win.
the code could even be made simpler if we throw out the --time-stamp check and
accept things based purely on their name. simply leverage AC_PATH_PROG.
-mike
signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
autoconf tests and stdcall name mangling
(Not sure which list is relevant, so I'm cross-posting to both mingw-users
and autoconf lists)
Hello lists,
when I'm cross compiling from linux x86_64 to 32-bit MinGW autoconf
refuses to detect getaddrinfo and define HAVE_GETADDRINFO. I've limited
the case to the following behaviour:
The getaddrinfo-link.c attached file is a simplification of what
AC_REPLACE_FUNCS(getaddrinfo) tries to compile and link. It fails to find
the symbol because gcc most probably doesn't use proper calling
conventions (stdcall). This is demonstrated by the build success of the
second attached program. So:
$ i686-w64-mingw32-gcc -o getaddrinfo-link getaddrinfo-link.c-lws2_32
/tmp/cctQtw3q.o:getaddrinfo-link.c:(.text+0xc): undefined reference to
`_getaddrinfo'
collect2: ld returned 1 exit status
$ i686-w64-mingw32-gcc -o getaddrinfo-link getaddrinfo-link-2.c-lws2_32
$
In the second case (getaddrinfo-link-2.c) compilation is successful
because the symbol linked is _getaddrinfo@16 which actually exists in
ws2_32 (verified it with nm). Here is the version of my toolchain:
$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 4.6.3
Any idea what's the proper way to use AC_REPLACE_FUNCS in this case?
Thanks in advance,
Dimitris
int __attribute__((__stdcall__)) getaddrinfo(int,int,int,int);
int
main ()
{
return getaddrinfo (0,0,0,0);
;
return 0;
}
int getaddrinfo ();
int
main ()
{
return getaddrinfo ();
;
return 0;
}
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf tests and stdcall name mangling
Hello, On 2013-05-22 20:22 +0200, Dimitrios Apostolou wrote: The getaddrinfo-link.c attached file is a simplification of what AC_REPLACE_FUNCS(getaddrinfo) tries to compile and link. It fails to find the symbol because gcc most probably doesn't use proper calling conventions (stdcall). This is demonstrated by the build success of the second attached program. So: [...] In the second case (getaddrinfo-link-2.c) compilation is successful because the symbol linked is _getaddrinfo@16 which actually exists in ws2_32 (verified it with nm). [...] [getaddrinfo-link-2.c] int __attribute__((__stdcall__)) getaddrinfo(int,int,int,int); [...] The fundamental problem, I think, is that you really need the proper headers included and AC_REPLACE_FUNCS does not seem to allow you to specify the includes. So you probably can't use this macro at all. You can use AC_LINK_IFELSE to fully specify the test program to compile and link, which is probably what you'll need to do here. This may still be tricky to get right. Alternately, Gnulib[1] has a getaddrinfo module[2] which may already do everything you need (although I have not used it). [1] https://gnu.org/s/gnulib [2] http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/getaddrinfo Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf tests and stdcall name mangling
On Wed, 22 May 2013, Dimitrios Apostolou wrote: (Not sure which list is relevant, so I'm cross-posting to both mingw-users and autoconf lists) Not a cross-post after all since mingw-users requires registration. I'd appreciate any help from autoconf people, just make sure you don't CC mingw-users so that you don't get a bounce (or just reply to this message). Hello lists, when I'm cross compiling from linux x86_64 to 32-bit MinGW autoconf refuses to detect getaddrinfo and define HAVE_GETADDRINFO. I've limited the case to the following behaviour: The getaddrinfo-link.c attached file is a simplification of what AC_REPLACE_FUNCS(getaddrinfo) tries to compile and link. It fails to find the symbol because gcc most probably doesn't use proper calling conventions (stdcall). This is demonstrated by the build success of the second attached program. So: $ i686-w64-mingw32-gcc -o getaddrinfo-link getaddrinfo-link.c-lws2_32 /tmp/cctQtw3q.o:getaddrinfo-link.c:(.text+0xc): undefined reference to `_getaddrinfo' collect2: ld returned 1 exit status $ i686-w64-mingw32-gcc -o getaddrinfo-link getaddrinfo-link-2.c -lws2_32 $ In the second case (getaddrinfo-link-2.c) compilation is successful because the symbol linked is _getaddrinfo@16 which actually exists in ws2_32 (verified it with nm). Here is the version of my toolchain: $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.6.3 Any idea what's the proper way to use AC_REPLACE_FUNCS in this case? Thanks in advance, Dimitris ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf tests and stdcall name mangling
On Wed, May 22, 2013 at 1:06 PM, Nick Bowler nbow...@elliptictech.com wrote: The fundamental problem, I think, is that you really need the proper headers included and AC_REPLACE_FUNCS does not seem to allow you to specify the includes. So you probably can't use this macro at all. You can use AC_LINK_IFELSE to fully specify the test program to compile and link, which is probably what you'll need to do here. This may still be tricky to get right. Alternately, Gnulib[1] has a getaddrinfo module[2] which may already do everything you need (although I have not used it). I wrote the attached macro to solve a closely related problem (looking for ntohl, not getaddrinfo; the way Winsock works, it's equivalent). Perhaps it will be useful to you. Going forward I think AC_*_FUNC[S] really need to grow a way to specify headers. Fake-declaring everything as char foo(); has been kinda silly for years now. zw winsock.m4 Description: Binary data ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf tests and stdcall name mangling
On 05/22/2013 02:12 PM, Zack Weinberg wrote: On Wed, May 22, 2013 at 1:06 PM, Nick Bowler nbow...@elliptictech.com wrote: The fundamental problem, I think, is that you really need the proper headers included and AC_REPLACE_FUNCS does not seem to allow you to specify the includes. So you probably can't use this macro at all. You can use AC_LINK_IFELSE to fully specify the test program to compile and link, which is probably what you'll need to do here. This may still be tricky to get right. Alternately, Gnulib[1] has a getaddrinfo module[2] which may already do everything you need (although I have not used it). I wrote the attached macro to solve a closely related problem (looking for ntohl, not getaddrinfo; the way Winsock works, it's equivalent). Perhaps it will be useful to you. Going forward I think AC_*_FUNC[S] really need to grow a way to specify headers. Fake-declaring everything as char foo(); has been kinda silly for years now. AC_CHECK_DECL (can I compile against this function when using the right headers) is a much better macro than AC_CHECK_FUNC (can I link against this symbol, and cross-my-fingers that the library actually exported it by this name and not some other due to aliasing or stdcall or ...). There are still a few corner cases where some platforms accidentally declare a function but fail to export it, so both styles of probes are still useful in practice; but generally you should try the DECL form first. Maybe this warrants a patch to the autoconf manual to point this out more emphatically; anyone want to take a stab at it? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
