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 bitro

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.overrid

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 sou

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 pac

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 req

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 "g

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 mingw-us

Re: autoconf tests and stdcall name mangling

2013-05-22 Thread Zack Weinberg
On Wed, May 22, 2013 at 1:06 PM, Nick Bowler 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 f

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 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