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 Peter O'Gorman
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


___
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


Re: [cygwin] cwrapper emits wrapper script

2007-06-05 Thread Peter O'Gorman


On Jun 1, 2007, at 4:20 PM, Charles Wilson wrote:



On Fri, 25 May 2007 11:27:08 -0400, Charles Wilson said:

On May 4, 2007, Charles Wilson wrote:

Ping?
http://lists.gnu.org/archive/html/libtool-patches/2007-04/ 
msg00088.html


Ping.


If it's Friday, it must be time for:


Could you please resend the patch itself, I am having issues with  
stripping the html markup from these links. (well, I can strip the  
html, but the resulting patch is not applying.)


Thanks,
Peter
--
Peter O'Gorman
http://pogma.com






-sysroot darwin

2007-06-05 Thread Peter O'Gorman

Hi,
On Mac OS X it is getting fairly common to configure with -isysroot  
in CFLAGS (hopefully will become less common again when all systems  
are fully fat in 10.5), this patch solves the issue that there are  
no .la files in the sysroots, but there are in /.


Ok for HEAD and 1.5?

Peter
--
Peter O'Gorman
http://pogma.com



sysroot.patch
Description: Binary data




Avoiding compiler warnings/errors with function pointers

2007-06-05 Thread Reuben Thomas

I have a line of code like this:

   if ((l_fn = lt_dlsym(l_st-lth, ladspa_descriptor)) == NULL) {

where l_fn is a function pointer. gcc says:

ladspa.c: In function 'sox_ladspa_getopts':
ladspa.c:114: warning: ISO C forbids assignment between function pointer and 
'void *'

There's no problem with this on my machine with my compiler settings, but if 
I wanted to write strictly conforming ISO C it looks like I'd have a 
problem; equally if I wanted this code to run on a machine where void * was 
not compatible with a function pointer.


Is there some way to avoid this problem?

--
http://rrt.sc3d.org/ | resident, a.  unable to leave (Bierce)


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Avoiding compiler warnings/errors with function pointers

2007-06-05 Thread Gary V. Vaughan

He Reuben,

On 4 Jun 2007, at 09:55, Reuben Thomas wrote:

I have a line of code like this:

   if ((l_fn = lt_dlsym(l_st-lth, ladspa_descriptor)) == NULL) {

where l_fn is a function pointer. gcc says:

ladspa.c: In function 'sox_ladspa_getopts':
ladspa.c:114: warning: ISO C forbids assignment between function  
pointer and 'void *'


There's no problem with this on my machine with my compiler  
settings, but if I wanted to write strictly conforming ISO C it  
looks like I'd have a problem; equally if I wanted this code to run  
on a machine where void * was not compatible with a function pointer.


Is there some way to avoid this problem?


What type does dlsym() return on that system?

If it is a void*, then I don't know of any portable way around it :-(

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Avoiding compiler warnings/errors with function pointers

2007-06-05 Thread Peter O'Gorman
On Tue, 2007-06-05 at 17:08 +0100, Gary V. Vaughan wrote:
 He Reuben,
 
 On 4 Jun 2007, at 09:55, Reuben Thomas wrote:
  I have a line of code like this:
 
 if ((l_fn = lt_dlsym(l_st-lth, ladspa_descriptor)) == NULL) {
 
  where l_fn is a function pointer. gcc says:
 
  ladspa.c: In function 'sox_ladspa_getopts':
  ladspa.c:114: warning: ISO C forbids assignment between function  
  pointer and 'void *'
 
  There's no problem with this on my machine with my compiler  
  settings, but if I wanted to write strictly conforming ISO C it  
  looks like I'd have a problem; equally if I wanted this code to run  
  on a machine where void * was not compatible with a function pointer.
 
  Is there some way to avoid this problem?
 
 What type does dlsym() return on that system?
 
 If it is a void*, then I don't know of any portable way around it :-(

freeBSD has a dlfunc() function that behaves like dlsym but returns a
function pointer, last time I looked it was implemented using a union...
wait, let me look again...:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libc/gen/dlfunc.c?rev=1.3;content-type=text%2Fplain

I think it is even in our TODO to have libltdl do this somehow, in the
meantime, Reuben can do something similar in his own code.

Peter


___
http://lists.gnu.org/mailman/listinfo/libtool