Re: dlfcn.h (libtool 1.5.23b)
On 5/30/07, deckrider [EMAIL PROTECTED] wrote: I don't know whether this is a bug or not ... I'm on: $ uname -a HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license $ libtool --version ltmain.sh (GNU libtool) 1.5.23b (1.1220.2.437 2007/02/17 09:08:45) $ automake --version automake (GNU automake) 1.10 $ autoconf --version autoconf (GNU Autoconf) 2.61 I'm getting this output when running configure: checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: dlfcn.h: proceeding with the compiler's result checking for dlfcn.h... yes I just noticed that it seems that the configuration that caused this was: AC_LANG(C++) AC_PROG_LIBTOOL However, if I change the order to this, the problem goes away: AC_PROG_LIBTOOL AC_LANG(C++) ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: dlfcn.h (libtool 1.5.23b)
On 6/5/07, deckrider [EMAIL PROTECTED] wrote: On 5/30/07, deckrider [EMAIL PROTECTED] wrote: I don't know whether this is a bug or not ... I'm on: $ uname -a HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license $ libtool --version ltmain.sh (GNU libtool) 1.5.23b (1.1220.2.437 2007/02/17 09:08:45) $ automake --version automake (GNU automake) 1.10 $ autoconf --version autoconf (GNU Autoconf) 2.61 I'm getting this output when running configure: checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: dlfcn.h: proceeding with the compiler's result checking for dlfcn.h... yes I just noticed that it seems that the configuration that caused this was: AC_LANG(C++) AC_PROG_LIBTOOL However, if I change the order to this, the problem goes away: AC_PROG_LIBTOOL AC_LANG(C++) My apologies, I think I omitted some important info ... it seems that AC_PROG_CPP is also a factor, thus the following causes the issue: AC_LANG(C++) AC_PROG_CPP AC_PROG_LIBTOOL And the issue is not present here: AC_LANG(C++) AC_PROG_LIBTOOL AC_PROG_CPP ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: dlfcn.h (libtool 1.5.23b)
On 6/5/07, Peter O'Gorman [EMAIL PROTECTED] wrote: On Tue, 2007-06-05 at 14:29 -0600, deckrider wrote: On 6/5/07, deckrider [EMAIL PROTECTED] wrote: On 5/30/07, deckrider [EMAIL PROTECTED] wrote: I don't know whether this is a bug or not ... I'm on: $ uname -a HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license $ libtool --version ltmain.sh (GNU libtool) 1.5.23b (1.1220.2.437 2007/02/17 09:08:45) $ automake --version automake (GNU automake) 1.10 $ autoconf --version autoconf (GNU Autoconf) 2.61 I'm getting this output when running configure: checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: dlfcn.h: proceeding with the compiler's result checking for dlfcn.h... yes I just noticed that it seems that the configuration that caused this was: AC_LANG(C++) AC_PROG_LIBTOOL However, if I change the order to this, the problem goes away: AC_PROG_LIBTOOL AC_LANG(C++) My apologies, I think I omitted some important info ... it seems that AC_PROG_CPP is also a factor, thus the following causes the issue: AC_LANG(C++) AC_PROG_CPP AC_PROG_LIBTOOL And the issue is not present here: AC_LANG(C++) AC_PROG_LIBTOOL AC_PROG_CPP It looks like AC_PROG_CPP is setting CPP to the empty string, from your config.log: configure:6181: conftest.cpp ../configure[6182]: conftest.cpp: not found. That should probably have been: /usr/ccs/lbin/cpp conftest.cpp or something similar. So, why does AC_PROG_CPP set CPP= for you? Not sure, but in the Makefile that was generated, it is this: CPP = cc +DD64 -Wl,+k -E ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: dlfcn.h (libtool 1.5.23b)
On 6/5/07, Peter O'Gorman [EMAIL PROTECTED] wrote: On Tue, 2007-06-05 at 16:04 -0600, deckrider wrote: On 6/5/07, Peter O'Gorman [EMAIL PROTECTED] wrote: So, why does AC_PROG_CPP set CPP= for you? Not sure, but in the Makefile that was generated, it is this: CPP = cc +DD64 -Wl,+k -E How odd! Could you post the entire config.log (compressed), thanks. Peter Here is a reduced configure.ac file, which I then ran 'autoreconf -fi against. Then I run './configure CC=cc +DD64 -Wl,+k CXX=aCC +DD64 -Wl,+k' And here is the resulting config.log. configure.ac Description: Binary data config.log.bz2 Description: BZip2 compressed data ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
dlfcn.h (libtool 1.5.23b)
I don't know whether this is a bug or not ... I'm on: $ uname -a HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license $ libtool --version ltmain.sh (GNU libtool) 1.5.23b (1.1220.2.437 2007/02/17 09:08:45) $ automake --version automake (GNU automake) 1.10 $ autoconf --version autoconf (GNU Autoconf) 2.61 I'm getting this output when running configure: checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: dlfcn.h: proceeding with the compiler's result checking for dlfcn.h... yes checking how to run the C++ preprocessor... aCC +DD64 -Wl,+k -E In the corresponding config.log is this: configure:6055: checking for unistd.h configure:6076: aCC +DD64 -Wl,+k -c -g conftest.cpp 5 configure:6082: $? = 0 configure:6098: result: yes configure:6125: checking dlfcn.h usability configure:6142: aCC +DD64 -Wl,+k -c -g conftest.cpp 5 configure:6148: $? = 0 configure:6162: result: yes configure:6166: checking dlfcn.h presence configure:6181: conftest.cpp ../configure[6182]: conftest.cpp: not found. configure:6187: $? = 127 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME impact-transport | #define PACKAGE_TARNAME impact-transport | #define PACKAGE_VERSION 2007.2.38 | #define PACKAGE_STRING impact-transport 2007.2.38 | #define PACKAGE_BUGREPORT [EMAIL PROTECTED] | #define PACKAGE impact-transport | #define VERSION 2007.2.38 | #define YYTEXT_POINTER 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | /* end confdefs.h. */ | #include dlfcn.h configure:6201: result: no configure:6207: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! configure:6209: WARNING: dlfcn.h: proceeding with the compiler's result configure:6234: checking for dlfcn.h configure:6242: result: yes configure:6265: checking how to run the C++ preprocessor configure:6301: aCC +DD64 -Wl,+k -E conftest.cpp I assume this was brought in from using libtool: # _LT_AC_CHECK_DLFCN # -- AC_DEFUN([_LT_AC_CHECK_DLFCN], [AC_CHECK_HEADERS(dlfcn.h)dnl ])# _LT_AC_CHECK_DLFCN My configure.ac includes: AC_PROG_LIBTOOL ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool --mode=execute gives LANG not found
ltmain.sh (GNU libtool) 1.5.23b (1.1220.2.437 2007/02/17 09:08:45) ia64-hp-hpux11.23 I'm seeing the following behavior: $ ./libtool --mode=execute ldd foo ./libtool[6827]: LANG: not found. ./libtool[6827]: LC_ALL: not found. ./libtool[6827]: LC_CTYPE: not found. ./libtool[6827]: LC_COLLATE: not found. ./libtool[6827]: LC_MESSAGES: not found. In my environment, each of these shell variables are not set. Regardless of the above output, the ldd command appears to work. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool