date:20070121

Re: no .so file on HPUX platform?

2007-01-21 Thread Ralf Wildenhues

* Ed Hartnett wrote on Fri, Jan 19, 2007 at 03:02:01AM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> > * Ed Hartnett wrote on Wed, Jan 03, 2007 at 05:50:38PM CET:
> >> 
> >> On our HPUX platform however, no libnetcdf.so file results. Yet the
> >> build seems to work OK. 
> >
> > The shared library extension should be '.sl'.  Please show
> >   ./libtool --config
> >
> > and
> >   ./libtool --features
> 
> Here they are:
> 
>  ./libtool --config
> 
> # Whether or not to build shared libraries.
> build_libtool_libs=no
[...]

> bash-2.04$ ./libtool --features
> host: hppa2.0w-hp-hpux11.00
> disable shared libraries
> enable static libraries

So something decided that shared libraries were not ok.  So we need to
take a closer look what did that.  I tried to build this:

> ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-daily.tar.gz

on a hppa2.0w-hp-hpux11.00 system using this:

> ./configure --enable-shared --enable-c-only

(but with a VPATH setup).  And I get
  enable shared libraries
  enable static libraries

and I get a nice library 'libsrc/.libs/libnetcdf.sl.4.0'.  'make check'
succeeds as well.

So, we're still at the head scratching stage.  Ed, could you provide
a build log, including config.log and configure output.  Probably that
won't even show it either, so if you have time, go and put
  set -x

in the second line of 'configure', rerun that and upload the output
somewhere.  If you must post it, be sure to bzip2-pack.

Cheers,
Ralf

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

Re: MS lib program in msys

2007-01-21 Thread Ralf Wildenhues

Hello Howard, Chris,

apologies for the delay.

* Howard Chu wrote on Mon, Jan 08, 2007 at 08:45:21PM CET:
> 
> Pretty sure "-" has been valid since at least Win95. Definitely this 
> should be changed.

OK, on my rather oldish installation it seems to work as well.
I have applied the patches below.

Cheers,
Ralf

HEAD:
2007-01-21  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw]:
Use `lib -OUT' rather than `lib /OUT' to avoid MSYS path
translation mangling.  Report by Christopher Hulbert.
* THANKS: Update.

Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.56
diff -u -r1.56 THANKS
--- THANKS  14 May 2006 08:20:11 -  1.56
+++ THANKS  21 Jan 2007 16:14:01 -
@@ -75,6 +75,7 @@
   Carl D. Roth [EMAIL PROTECTED]
   Chris P. Ross[EMAIL PROTECTED]
   Christian Biesinger  [EMAIL PROTECTED]
+  Christopher Hulbert  [EMAIL PROTECTED]
   Dalibor Topic[EMAIL PROTECTED]
   Daniel Reed  [EMAIL PROTECTED]
   DJ Delorie   [EMAIL PROTECTED]
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.86
diff -u -r1.86 libtool.m4
--- libltdl/m4/libtool.m4   19 Oct 2006 05:06:14 -  1.86
+++ libltdl/m4/libtool.m4   21 Jan 2007 16:12:29 -
@@ -1,7 +1,7 @@
 # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
 #
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006 Free Software Foundation, Inc.
+# 2006, 2007 Free Software Foundation, Inc.
 #
 # This file is part of GNU Libtool:
 # Originally by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
@@ -12,7 +12,7 @@
 
 m4_define([_LT_COPYING], [dnl
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006 Free Software Foundation, Inc.
+# 2006, 2007 Free Software Foundation, Inc.
 #
 # This file is part of GNU Libtool:
 # Originally by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
@@ -587,7 +587,7 @@
 m4_ifset([AC_PACKAGE_VERSION], [ AC_PACKAGE_VERSION])
 configured by $[0], generated by m4_PACKAGE_STRING.
 
-Copyright (C) 2006 Free Software Foundation, Inc.
+Copyright (C) 2007 Free Software Foundation, Inc.
 This config.lt script is free software; the Free Software Foundation
 gives unlimited permision to copy, distribute and modify it."
 
@@ -4466,7 +4466,7 @@
   # The linker will automatically build a .lib file if we build a DLL.
   _LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
   # FIXME: Should let the user specify the lib program.
-  _LT_TAGVAR(old_archive_cmds, $1)='lib /OUT:$oldlib$oldobjs$old_deplibs'
+  _LT_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
   _LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
   _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
   ;;

branch-1-5:
2007-01-21  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [cygwin, mingw]:
Use `lib -OUT' rather than `lib /OUT' to avoid MSYS path
translation mangling.  Report by Christopher Hulbert.
* THANKS: Update.

Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.34.2.19
diff -u -r1.34.2.19 THANKS
--- THANKS  14 May 2006 08:21:23 -  1.34.2.19
+++ THANKS  21 Jan 2007 16:13:47 -
@@ -75,6 +75,7 @@
   Carl D. Roth [EMAIL PROTECTED]
   Chris P. Ross[EMAIL PROTECTED]
   Christian Biesinger  [EMAIL PROTECTED]
+  Christopher Hulbert  [EMAIL PROTECTED]
   Dalibor Topic[EMAIL PROTECTED]
   Daniel Reed  [EMAIL PROTECTED]
   DJ Delorie   [EMAIL PROTECTED]
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.166
diff -u -r1.314.2.166 libtool.m4
--- libtool.m4  19 Oct 2006 05:05:55 -  1.314.2.166
+++ libtool.m4  21 Jan 2007 16:13:28 -
@@ -1,5 +1,5 @@
 # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
-## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006
+## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007
 ## Free Software Foundation, Inc.
 ## Originally by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
 ##
@@ -4305,7 +4305,7 @@
 # Generated automatically by $PROGRAM (GNU $PACKAGE $VERSION$TIMESTAMP)
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 #
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 
2006
+# Copyright (C) 1996, 1997, 1998, 1999

RE: windows static archive, missing symbols

2007-01-21 Thread Duft Markus

Howard Chu <> wrote:
> Bob Rossi wrote:
>> Hi,
>> 
>> I've got a quick question hopefully. I'm building pcre on windows.
>> I've 
>> been able to build it into a dll and link against it with a small
>> program. However, when I build a static library, and link it with a
>> small program, I get the missing symbols error.
>> 
>> I know the symbols are in the library because nm tells me so,
>>   $ nm -g
>>   /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep
>> compile   libpcre_la-pcre_compile.o: 5550 T _pcre_compile 
>> 
>> Here is the link line of the small program,
>>   $ gcc-4.1 -g -Wall -o test test.c
>> -L/home/bobbybrasko/download/pcre/pcre/install/lib \ 
>> -lpcreposix -lpcre
>>   -I/home/bobbybrasko/download/pcre/pcre/install/include
>>   C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main':
>>  
>>
>> C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13:
>> undefined reference to `_imp__pcre_compile' 
>> collect2: ld returned 1 exit status   
>> 
>> Does anyone understand why I'd be getting these errors? Are .def
>> files 
>> important for static windows libraries or only for dll's? Any advice?
>> 
> First of all, obviously "_imp__pcre_compile" is not the same as
> "_pcre_compile" so the error message is legitimate - the symbol that
> it's actually looking for is not there.
> 
> The next question is, why is it looking for an import symbol instead
> of using the real symbol. The answer to that must lie in your header
> files; they probably declare the function to be a DLL export, which
> causes the compiler to generate references to an import symbol. Have
> a look at your header files. Remove any DLL declspec's on any
> function declarations you find there; modern linkers don't need them.
> I.e., the GNU linker is 
> smart enough to use an import symbol in place of a reference to a real
> symbol. Apparently it won't do the opposite.
> 
> Unfortunately if a library exports variables as well, you need to
> preserve the export declspecs there. This means for any Windows
> library that you use, you have to know whether you will be using a
> static or a dynamic version, whenever compiling an app that uses the
> library. Very braindead, and there's no solution to that problem. The
> workaround is to never export variables from your libraries, only
> functions/accessor methods. 

Hi!

There is a solution to this problem, but for now it is only present in
interix-wgcc, which uses cl.exe and not gcc/ld. The solution is, to make
a wrapper generate symbols whenusing static libraries, to make the
linker think it is a shared library... Works perfectly ;o)

Cheers, Markus



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

Problem with post(un)install cmds

2007-01-21 Thread Duft Markus

Hi!

I wrote the following two for libtool 1.5.22 and they worked perfectly.
Now i just copied them over to libtool 2.1a (CVS HEAD), and it doesn't
seem to work (the directory structure is the same, so this is ok...). I
believe that there is a difference in how libtool executes these code
snippets, is this correct?? If yes, how can i adapt this, so it works
with  libtool 2?

postinstall_cmds='base_file=`basename \${file}`~
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo
\$dlname'\''`~
dldir=$destdir/`dirname \$dlpath` ~
set dummy `ls -l $dir/\$dlname*.dll` ~
while test -n "\${3}" ; do shift; done ~
dllname=`basename ${2}` ~
test -d \${dldir}/../bin || mkdir -p \${dldir}/../bin ~
$install_prog $dir/$dllname \$dldir/../bin/$dllname ~
chmod a+x \$dldir/../bin/$dllname'

postuninstall_cmds='dlpath=`$SHELL 2>&1 -c '\''. $file; echo
\$dlname'\''`~
set dummy `ls -l $dir/../bin/\$dlname*.dll` ~
while test -n "\${3}" ; do shift; done ~
$rm ${2}'


Thanks in Advance,
Cheers, Markus


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

Re: no .so file on HPUX platform?

Re: MS lib program in msys

RE: windows static archive, missing symbols

Problem with post(un)install cmds

4 matches

Site Navigation

Mail list logo

Footer information