Re: [PATCH 0/2] Modernize header checks
Zack Weinberg za...@panix.com writes: Second, it cleans up AC_INCLUDES_DEFAULT and all the other canned tests so that they don't waste time checking for ISO C90 headers, which are now ubiquitous (stddef.h, stdlib.h, string.h, wchar.h, wctype.h, locale.h, time.h) and don't use pre-standard headers that were replaced by C90 headers at all (memory.h and strings.h). I *think* your patch would remove strings.h from the list of headers that are probed by default by Autoconf, and hence remove HAVE_STRINGS_H from the preprocessor directives set by Autoconf. If so, note that removing strings.h from the list of headers that are probed by default will cause backwards compatibility issues. One still must include strings.h (not string.h) according to POSIX in order to get strcasecmp and friends, and some operating systems (specifically at least some versions of FreeBSD) do actually enforce that and do not prototype those functions in string.h. I'm quite sure there is code out there that assumes that Autoconf will probe for strings.h as a side effect of other probes and set HAVE_STRINGS_H, and therefore doesn't probe for it explicitly. (I maintain some of it, in fact.) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 0/2] Modernize header checks
On 05/31/2013 11:07 AM, Eric Blake wrote: If so, note that removing strings.h from the list of headers that are probed by default will cause backwards compatibility issues. One still must include strings.h (not string.h) according to POSIX in order to get strcasecmp and friends, and some operating systems (specifically at least some versions of FreeBSD) do actually enforce that and do not prototype those functions in string.h. I'm quite sure there is code out there that assumes that Autoconf will probe for strings.h as a side effect of other probes and set HAVE_STRINGS_H, and therefore doesn't probe for it explicitly. (I maintain some of it, in fact.) Yes, there is a bunch of code that non-portably assumes they can use strcasecmp or ffs without including strings.h. On the other hand, strings.h is available on pretty much ALL platforms that use free software compilers (according to gnulib, only ancient Minix 3.1.8 and non-free MSVC 9 have problems with assuming strings.h exists and is self-contained; but mingw does not have this issue). Thus, you generally don't need to use HAVE_STRINGS_H, but can just blindly include it, unless your package is trying to be portable to a rather unforgiving toolchain. That said, would it hurt if autoconf just unconditionally defined the macros that were previously conditionally defined by a probe, so that code that was relying on HAVE_STRINGS_H instead of blind inclusion will still compile? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
Eric Blake ebl...@redhat.com writes: Yes, there is a bunch of code that non-portably assumes they can use strcasecmp or ffs without including strings.h. On the other hand, strings.h is available on pretty much ALL platforms that use free software compilers (according to gnulib, only ancient Minix 3.1.8 and non-free MSVC 9 have problems with assuming strings.h exists and is self-contained; but mingw does not have this issue). Thus, you generally don't need to use HAVE_STRINGS_H, but can just blindly include it, unless your package is trying to be portable to a rather unforgiving toolchain. Sure, I can add the explicit probe for strings.h to my code or drop the #ifdef depending on the portability requirements (and in fact will do so regardless, since whether or not this change is made it's a good idea). My point wasn't that, but rather that this change will break backward compatibility for Autoconf users, and I wanted to make sure that people were aware of that. There is code that includes strings.h protected by #ifdef HAVE_STRINGS_H which currently compiles correctly and will stop compiling correctly after the configure script is rebuilt with this change. All of the other changes that Zack discussed look backward-compatible to me except in the area of portability to entirely obsolete systems. This one stood out because it would break compilation of some packages on modern, maintained FreeBSD systems because it changes current assumptions about what the standard Autoconf header probes do. This behavior is not currently clearly documented, but I will point out that the current documentation of AC_INCLUDES_DEFAULT shows use of the HAVE_STRINGS_H define without any mention of any other required checks. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 0/2] Modernize header checks
Eric Blake ebl...@redhat.com writes: That said, would it hurt if autoconf just unconditionally defined the macros that were previously conditionally defined by a probe, so that code that was relying on HAVE_STRINGS_H instead of blind inclusion will still compile? That would certainly resolve my concern. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 2/2] Modernize AC_INCLUDES_DEFAULT and friends.
On 05/30/2013 03:19 PM, Zack Weinberg wrote: * lib/autoconf/headers.m4 (_AC_INCLUDES_DEFAULT_REQUIREMENTS): Include stddef.h, stdlib.h, and string.h unconditionally. Don't include strings.h or memory.h at all. strings.h is still a standardized header, its just that the standards assigned it very little content. +- AC_INCLUDES_DEFAULT has been streamlined. It now assumes that + ISO C90 headers are available unconditionally (stddef.h, stdio.h, + stdlib.h, string.h) and does not use pre-standard headers at all + (memory.h, strings.h). Therefore, this NEWS entry needs to be tweaked for accuracy (only memory.h is pre-standard), which may also mean tweaking your code. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
On Fri, May 31, 2013 at 12:39 PM, Russ Allbery r...@stanford.edu wrote: Zack Weinberg za...@panix.com writes: I *think* your patch would remove strings.h from the list of headers that are probed by default by Autoconf, and hence remove HAVE_STRINGS_H from the preprocessor directives set by Autoconf. That's right. If so, note that removing strings.h from the list of headers that are probed by default will cause backwards compatibility issues. One still must include strings.h (not string.h) according to POSIX in order to get strcasecmp and friends, and some operating systems (specifically at least some versions of FreeBSD) do actually enforce that and do not prototype those functions in string.h. I'm quite sure there is code out there that assumes that Autoconf will probe for strings.h as a side effect of other probes and set HAVE_STRINGS_H, and therefore doesn't probe for it explicitly. (I maintain some of it, in fact.) I had been under the impression that everything one still wanted out of strings.h was also specified to be in string.h (in particular both strcasecmp and ffs). I see now that this is wrong. For the short term I'm good with putting a conditional #include of strings.h and a probe for it back into AC_INCLUDES_DEFAULT (MSVC is the only common platform that doesn't seem to have it, but that's true even in the very latest version). However, I'd like to come up with a transition plan so we don't have to treat this as an almost-always-wanted header forever. We don't have any tooling for a you need to start probing for this manually warning, do we? An unconditional AC_DIAGNOSE would be spurious for most people... I'm also good with restoring compatibility AC_DEFINEs for the C90 headers (HAVE_STRING_H, HAVE_STDDEF_H, HAVE_STDLIB_H, I think that was all) just to be safe.
Re: [PATCH 0/2] Modernize header checks
On 05/31/2013 11:51 AM, Zack Weinberg wrote: I had been under the impression that everything one still wanted out of strings.h was also specified to be in string.h (in particular both strcasecmp and ffs). I see now that this is wrong. POSIX allows (but not requires) strcasecmp to be made available in string.h (basically, the entire str* namespace is reserved for use by string.h - so BSD's efforts to hide strcasecmp from string.h when strictly-conforming may be a bit too harsh); but POSIX does NOT allow ffs to be made available in string.h. Then again, most users specifically ask for non-POSIX extensions via AC_USE_SYSTEM_EXTENSIONS, at which point namespace pollution of ffs via string.h is fair game. But at the end of the day, the only portable way to rely on strcasecmp or ffs is to use strings.h. For the short term I'm good with putting a conditional #include of strings.h and a probe for it back into AC_INCLUDES_DEFAULT (MSVC is the only common platform that doesn't seem to have it, but that's true even in the very latest version). However, I'd like to come up with a transition plan so we don't have to treat this as an almost-always-wanted header forever. We don't have any tooling for a you need to start probing for this manually warning, do we? An unconditional AC_DIAGNOSE would be spurious for most people... ifnames(1) is part of the Autoconf package, and SHOULD be the tool that does this warning. But it hasn't seen much use or much love lately. I'm also good with restoring compatibility AC_DEFINEs for the C90 headers (HAVE_STRING_H, HAVE_STDDEF_H, HAVE_STDLIB_H, I think that was all) just to be safe. Yes, any macros that were previously defined on always-successful probes must continue to be defined even after your cleanup. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
On 2013-05-31 19:19, Eric Blake wrote: That said, would it hurt if autoconf just unconditionally defined the macros that were previously conditionally defined by a probe, so that code that was relying on HAVE_STRINGS_H instead of blind inclusion will still compile? How would one do to be portable to both some versions of FreeBSD and MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs HAVE_STRINGS_H to be defined and one needs to not have it defined. Sounds evil to unconditionally define it under those circumstances. Or have I misunderstood something? Cheers, Peter
Re: [PATCH 0/2] Modernize header checks
On 05/31/2013 03:26 PM, Peter Rosin wrote:
On 2013-05-31 19:19, Eric Blake wrote:
That said, would it hurt if autoconf just unconditionally defined the
macros that were previously conditionally defined by a probe, so that
code that was relying on HAVE_STRINGS_H instead of blind inclusion will
still compile?
How would one do to be portable to both some versions of FreeBSD and
MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs
HAVE_STRINGS_H to be defined and one needs to not have it defined.
Sounds evil to unconditionally define it under those circumstances. Or
have I misunderstood something?
Portable only to open toolchains, your choice of:
1. Simplest:
#include strings.h
void foo() { strcasecmp(a, b); }
2. Verbose:
#include string.h
#if HAVE_STRINGS_H
# include strings.h
#endif
void foo() { strcasecmp(a, b); }
Portable to MSVC toolchains:
3. Verbose:
#include string.h
#if HAVE_STRINGS_H
# include strings.h
#endif
void foo() { strcasecmp(a, b); }
The upshot is that if autoconf only cares about open toolchains (such as
gcc on mingw when porting code to Windows), then it can unconditionally
define HAVE_STRINGS_H (it must define this macro for back-compat to
existing code that only includes strings.h inside that test). But if
autoconf still wants to cater to MSVC, then it must have a way to
specify that the existence of strings.h must be probed. This way does
not have to be default; most packages need a LOT more work before they
could compile under MSVC in the first place, so asking users that care
about such setups to modify configure.ac to set some witness variable in
order to force a probe instead of a blind define seems okay to me.
Personally, I don't care if any of my packages ever compile under MSVC -
that's due in part to Microsoft's lack of regards towards standards and
unwillingness to provide free tools (free license, not free price); in
part due to the fact that gcc on mingw does just as well; and in part
due to the fact that no one who does care has ever submitted a patch to
any of my project mailing lists even trying to get that to work.
Therefore, I would argue that future autoconf needs a way to minimize
useless probing for strings.h, and it would be nicer (in my eyes) if
this mode were the default; although I could also be persuaded that it
is safer to have the no-probe mode only if I add a witness macro to my
configure.ac.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/2] Modernize header checks
Peter Rosin p...@lysator.liu.se writes: On 2013-05-31 19:19, Eric Blake wrote: That said, would it hurt if autoconf just unconditionally defined the macros that were previously conditionally defined by a probe, so that code that was relying on HAVE_STRINGS_H instead of blind inclusion will still compile? How would one do to be portable to both some versions of FreeBSD and MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs HAVE_STRINGS_H to be defined and one needs to not have it defined. Sounds evil to unconditionally define it under those circumstances. Or have I misunderstood something? Autoconf doesn't work with MSVC directly so far as I know. All of the packages I have that are ported to MSVC have a separate hand-written config.h that's used for MSVC builds, and in that file one simply doesn't define HAVE_STRINGS_H. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: [PATCH 0/2] Modernize header checks
On 2013-06-01 00:06, Russ Allbery wrote: Peter Rosin p...@lysator.liu.se writes: On 2013-05-31 19:19, Eric Blake wrote: That said, would it hurt if autoconf just unconditionally defined the macros that were previously conditionally defined by a probe, so that code that was relying on HAVE_STRINGS_H instead of blind inclusion will still compile? How would one do to be portable to both some versions of FreeBSD and MSVC, then? (MSVC 10 also lacks strings.h, btw) One camp needs HAVE_STRINGS_H to be defined and one needs to not have it defined. Sounds evil to unconditionally define it under those circumstances. Or have I misunderstood something? Autoconf doesn't work with MSVC directly so far as I know. All of the packages I have that are ported to MSVC have a separate hand-written config.h that's used for MSVC builds, and in that file one simply doesn't define HAVE_STRINGS_H. What do you mean directly? MSYS can drive a build using MSVC as toolchain (instead of MinGW) just fine. I do it all the time. Cheers, Peter
Re: Help with static linking
Statically linking libc is a recipe for disaster, so either read and understand why, or just take my word for it. I don't quite understand why you think you need the rest linked statically, BUT the easiest way to do that would be to add LT_INIT to configure.ac to use Libtool, and add --static-libtool-libs to the target's LDFLAGS. That will cause all of the Libtool libraries to be linked statically when possible. If you are only targeting Linux desktop systems, png, gobject, gio, and glib should already be there, and in most cases already in memory, so you will benefit from zero additional memory use for the code pages. This also goes for all the dependencies of these libraries. I'm not familiar with zzip, so if it isn't a Libtool library you will have to make sure it is linked like this: -Wl,-static -lzzip -Wl,call_shared I don't have a computer in front of me, so YMMV, you should man ld to make sure those flags are correct. HTH, Robert Boehne Kip Warner k...@thevertigo.com wrote: Hey lists, Sorry for posting on both autoconf and automake lists. I wasn't sure which one would be more appropriate for this problem. I know this has come up before, judging by the archives, but I cannot figure out the best way to have my executable statically link against certain dependencies. This is needed because it executes off of optical media and I cannot always guarantee that the user's runtime environment will have the needed dependencies and shipping them shared would be a maintenance nightmare. The dynamic dependencies, according to objdump, are the following... Dynamic Section: NEEDED libgio-2.0.so.0 NEEDED libgobject-2.0.so.0 NEEDED libglib-2.0.so.0 NEEDED libzzip-0.so.13 NEEDED libpng12.so.0 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libpthread.so.0 NEEDED libc.so.6 libc, pthreads, the C++ runtime, etc., are safe to assume are available, but the rest I'd like to statically link against. Actually, I'd prefer to statically link against everything that I can if possible. But the ones for certain I know I should be able to statically link against are at least libzzip and libpng. I know there a number of different approaches to doing this, but from the pieces scattered in various places, it was difficult to determine the most reliable and recommended approach. For instance, I've tried 'myproduct_LDADD = $(LIBINTL) -static', but objdump still reports all of the above dynamic dependencies, so maybe it's not doing what I thought it was suppose to do. This is my configure.ac: http://rod.gs/Jwo This is my Makefile.am: http://rod.gs/Lwo Any help appreciated. Respectfully, -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Error while building autoconf-2.69
I am trying to build autoconf-2.69. The ./configure command runs fine, but when
i do make check, i get these errors
standards.texi:3229: Unknown command `guilsinglleft'.
standards.texi:3229: Misplaced {.
standards.texi:3229: Misplaced }.
standards.texi:3229: Unknown command `guilsinglright'.
standards.texi:3229: Misplaced {.
standards.texi:3229: Misplaced }.
makeinfo: Removing output file `standards.info' due to errors; use --force to
preserve.
make[2]: *** [standards.info] Error 1
make[2]: Leaving directory
`/home/MTS-AERO_Work-15/Aero_Design-15/Internship/TAU_Interpolation/Netcdf_libraries/autoconf-2.69/doc'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/MTS-AERO_Work-15/Aero_Design-15/Internship/TAU_Interpolation/Netcdf_libraries/autoconf-2.69'
make: *** [check] Error 2
Can you help. Please reply soon.
The information in this e-mail is confidential. The contents may not be
disclosed or used by anyone other than the addressee. Access to this e-mail by
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of
this e-mail as it has been sent over public networks. If you have any concerns
over the content of this message or its Accuracy or Integrity, please contact
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus
scanning software but you should take whatever measures you deem to be
appropriate to ensure that this message and any attachments are virus free.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Error while building autoconf-2.69
On 05/31/2013 12:24 AM, DUBEY, Abir (Intern) wrote: I am trying to build autoconf-2.69. The ./configure command runs fine, but when i do make check, i get these errors standards.texi:3229: Unknown command `guilsinglleft'. What version of makeinfo are you using? Most likely, this is a case of you using really old tools. At any rate, doc/standards.info is not maintained by autoconf, but is pulled from the gnustandards repository; you may want to redirect your bug report to bug-standa...@gnu.org and mention what version of tools you are using, in case it is decided upstream to make standards.texi compatible to an older toolset. The information in this e-mail is confidential. Sorry, but by posting to a publicly-archived mailing list, you have rendered this disclaimer unenforceable. Next time, consider posting from an account that does not slam your employer's legalese trash at the bottom. -- 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: Help with static linking
On Thu, May 30, 2013 at 10:30 PM, Kip Warner k...@thevertigo.com wrote: The ones for certain I know I should be able to statically link against are at least libzzip and libpng. You have PKG_CHECK_MODULES([libzzip], [zziplib], [have_zzip=yes], [have_zzip=no]) Have you seen https://bugs.freedesktop.org/show_bug.cgi?id=19541 ? Maybe try PKG_CHECK_MODULES_STATIC or PKG_CONFIG=pkg-config --static Never heard of libzzip, I can see why you don't want to expect it to be on the user's system already. Is libpng a problem because its soname isn't the same everywhere yet? http://www.linuxbase.org/navigator/browse/lib_single.php?cmd=list-by-nameSection=ABILname=libpng12 - Dan ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
