Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

2013-05-22 Thread Pavel Raiskup
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

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

2013-05-22 Thread Mike Frysinger
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

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

2013-05-22 Thread Mike Frysinger
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

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

2013-05-22 Thread Mike Frysinger
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

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

2013-05-22 Thread Eric Blake
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

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

2013-05-22 Thread Mike Frysinger
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

autoconf tests and stdcall name mangling

2013-05-22 Thread Dimitrios Apostolou
(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

Re: autoconf tests and stdcall name mangling

2013-05-22 Thread Nick Bowler
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).

Re: autoconf tests and stdcall name mangling

2013-05-22 Thread Dimitrios Apostolou
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

Re: autoconf tests and stdcall name mangling

2013-05-22 Thread Zack Weinberg
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

Re: autoconf tests and stdcall name mangling

2013-05-22 Thread Eric Blake
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