Re: dlfcn.h (libtool 1.5.23b)

2007-06-05 Thread deckrider

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)

2007-06-05 Thread deckrider

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)

2007-06-05 Thread deckrider

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)

2007-06-05 Thread deckrider

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)

2007-05-30 Thread deckrider

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

2007-04-10 Thread deckrider

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