Re: test for preprocessor fails on iPhoneOS

It looks like the user can't compile a file like this: #include int big = INT_MAX; because the compiler in the user's environment will say "error: Unsupported architecture". If so, this sounds like it's a configuration problem on the user's side, as C code like that should work regardless o

Re: recommended sequence to add libtool to an existing configure.ac

Thanks Zack, this helps clarify the issue a lot. --Ed On Thursday, February 6, 2014, Ed Mansky <man...@mindspring.com> wrote: Which of the macros : AC_CANCAONICAL_SYSTEM AC_CANONICAL_HOST AC_CANONICAL_BUILD AC_CANONICAL_TARGET should one use in a

Re: uint64_t fails with C++ (again)

>> I tend to work around these sorts of glitches using Gnulib; its >> stdint module fixes the portability problem with >> __STDC_LIMIT_MACROS that I know about. Admittedly Gnulib is not >> for everybody. > > Hehe. I use gnulib, so this is just fine for me. Will test `stdint' module soon – I've

Re: uint64_t fails with C++ (again)

>> Will this problem be handled in a forthcoming autoconf release? > > I'm afraid I don't understand the problem yet, as your original > email defined __STDC_LIMIT_MACROS, but now you're saying that > -D__STDC_LIMIT_MACROS fixes the problem. Indeed, doing ./configure CC=g++ CPPFLAGS="-D__STDC

Re: uint64_t fails with C++ (again)

Werner LEMBERG wrote: Will this problem be handled in a forthcoming autoconf release? I'm afraid I don't understand the problem yet, as your original email defined __STDC_LIMIT_MACROS, but now you're saying that -D__STDC_LIMIT_MACROS fixes the problem. That being said, my guess is that it's

Re: uint64_t fails with C++ (again)

>> Repeating your test verbatim I get the #error message! > > How about if you compile with the following command instead? > > g++ -D__STDC_LIMIT_MACROS -c t.cc > > That fixes the problem on RHEL 6.4, anyway. It works for me, too. Will this problem be handled in a forthcoming autoconf release

Re: uint64_t fails with C++ (again)

Werner LEMBERG wrote: Repeating your test verbatim I get the #error message! I'm not too surprised, since you're probably using a pre-C++11 system. I get the same #error on RHEL 6.4, which uses g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), which is older even than your compiler. How about if

Re: Passing -fno-lto by default?

On 2014.02.07 at 08:44 +0100, Thomas Jahns wrote: > On Feb 6, 2014, at 22:00 , Russ Allbery wrote: > > Why would one not instead build the object and then use objdump on > > it to > > look at the exported symbols? It's still not ideally portable, but it > > seems like it should be more portable