Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
On 11/30/2009 12:42 AM, Ralf Wildenhues wrote: I don't see a warning to that end, my system declares strrchr as #includestring.h char *strrchr(const char *s, int c); What does yours (darwin?) do instead? Actually, this was on Fedora 11, gcc-4.4.1, glibc-2.10, which for c++, declares strrchr and strchr as having the same return type as the first argument, char* for a char* argument, and const char* for a const char* argument: extern C++ { extern char *strrchr (char *__s, int __c) throw () __asm (strrchr) __attribute__ ((__pure__)) __attribute__ ((__nonnull__ (1))); extern __const char *strrchr (__const char *__s, int __c) throw () __asm (strrchr) __attribute__ ((__pure__)) __attribute__ ((__nonnull__ (1))); http://udrepper.livejournal.com/20948.html Peter -- Peter O'Gorman http://pogma.com
Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
* Peter Rosin wrote on Mon, Nov 30, 2009 at 08:15:22PM CET: Right, this is perhaps a better fix? Yes, please apply, thanks. Cheers, Ralf 2009-11-30 Peter Rosin p...@lysator.liu.se Please C++ compilers when calling strrchr. * libltdl/ltdl.c (has_library_ext): Match the return type of strrchr with the first argument to please C++ compilers. Report by Peter O'Gorman.
Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
Den 2009-11-30 20:16 skrev Ralf Wildenhues: Yes, please apply, thanks. Done. Cheers, Peter -- They are in the crowd with the answer before the question. Why do you dislike Jeopardy?
Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
On 11/29/2009 04:12 PM, Ralf Wildenhues wrote: I've built Libtool and run the testsuites with CC=g++ on GNU/Linux, the following patch fixes the fallout. Pushed as obvious. You did 'make check CC=g++'? or './configure CC=g++; make; make check'? IIRC libltdl itself did not built for me with make distcheck CC=g++ not because of test suite failures, but because libltdl itself fails to build. A simple cast allows it to build: diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c index 24ee13f..270d528 100644 --- a/libltdl/ltdl.c +++ b/libltdl/ltdl.c @@ -1511,7 +1511,7 @@ has_library_ext (const char *filename) assert (filename); - ext = strrchr (filename, '.'); + ext = (char *)strrchr (filename, '.'); if (ext ((streq (ext, archive_ext)) #if defined(LT_MODULE_EXT) But, I think there were objections to adding random casts like this when it came up before? Anyway, thanks for fixing the testsuite failures with this :) Peter -- Peter O'Gorman http://pogma.com
Re: Fix bindir and dlopen tests for C++ compilers (CC=g++).
Hi Peter, * Peter O'Gorman wrote on Mon, Nov 30, 2009 at 05:15:25AM CET: On 11/29/2009 04:12 PM, Ralf Wildenhues wrote: I've built Libtool and run the testsuites with CC=g++ on GNU/Linux, the following patch fixes the fallout. Pushed as obvious. You did 'make check CC=g++'? or './configure CC=g++; make; make check'? Actually I tried both. The latter brought me ../libtool/libltdl/ltdl.c: In function 'int find_module(lt__handle**, const char*, const char*, const char*, const char*, int, lt__advise*)': ../libtool/libltdl/ltdl.c:533: warning: deprecated conversion from string constant to 'char*' ../libtool/libltdl/ltdl.c: In function 'int try_dlopen(lt__handle**, const char*, const char*, lt__advise*)': ../libtool/libltdl/ltdl.c:1263: warning: deprecated conversion from string constant to 'char*' which I'm not sure how to best fix in a future-proof way- IIRC libltdl itself did not built for me with make distcheck CC=g++ not because of test suite failures, but because libltdl itself fails to build. A simple cast allows it to build: I don't see a warning to that end, my system declares strrchr as #include string.h char *strrchr(const char *s, int c); What does yours (darwin?) do instead? --- a/libltdl/ltdl.c +++ b/libltdl/ltdl.c @@ -1511,7 +1511,7 @@ has_library_ext (const char *filename) assert (filename); - ext = strrchr (filename, '.'); + ext = (char *)strrchr (filename, '.'); if (ext ((streq (ext, archive_ext)) #if defined(LT_MODULE_EXT) But, I think there were objections to adding random casts like this when it came up before? Well, the cast only looks random as long as we don't know a good rationale for it, I guess. Thanks, Ralf