[sr #111038] QNX version_type handling is wrong

[anonymous]

Additional Item Attachment, sr #111038 (group libtool):

File name: 0001-ltmain.in-update-QNX-version_type-handling.patch Size:1 KB
   



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-0ba62ed3a038e8b50b65b09fae7f127f4f071c33.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111038] QNX version_type handling is wrong

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111038>

 Summary: QNX version_type handling is wrong
   Group: GNU Libtool
   Submitter: None
   Submitted: Fri 22 Mar 2024 05:01:30 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: sw...@blackberry.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Fri 22 Mar 2024 05:01:30 PM UTC By: Anonymous
SONAME versioning on QNX OS works just like all the other popular ELF targets
and has done so for the last decade. The current libtool functionality breaks
for projects that follow the libtool SONAME versioning protocol correctly.

The attached patch is regularly applied by upstream to fix this problem.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?111038>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111002] regression in libtool 2.4.7: build error in ncurses

[anonymous]

URL:
  <https://savannah.gnu.org/support/?111002>

 Summary: regression in libtool 2.4.7: build error in ncurses 
   Group: GNU Libtool
   Submitter: None
   Submitted: Sat 06 Jan 2024 07:54:04 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: klu...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Sat 06 Jan 2024 07:54:04 AM UTC By: Anonymous
ncurses 6.4 can be built with libtool when configured with `--with-libtool`
option. I found that while building with libtool 2.4.6 it was successful,
building ncurses with libtool 2.4.7 fails with attached error.

+ cd ../obj_lo
+ libtool --tag=CXX --silent --mode=compile c++ -DHAVE_CONFIG_H
-DBUILDING_NCURSES_CXX -I../c++ -I. -I../include -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -DNDEBUG -O2 -c ../c++/demo.cc -o ../obj_lo/demo.lo
mv: 'demo.o' and '../obj_lo/demo.o' are the same file
make[1]: *** [Makefile:268: ../obj_lo/demo.lo] Error 1


In the attachments, there are:

* ncurses 6.4 config.guess
* log of successful configure and make of ncurses 6.4 using libtool 2.4.6 
* log of failed configure and make of ncurses 6.4 using libtool 2.4.7






___
File Attachments:


---
Name: config.guess  Size: 49KiB
<http://savannah.gnu.org/support/download.php?file_id=55527>
---
Name: ncurses.error.libtool_247.log  Size: 152KiB
<http://savannah.gnu.org/support/download.php?file_id=55528>
---
Name: ncurses.success.libtool_246.log  Size: 149KiB
<http://savannah.gnu.org/support/download.php?file_id=55529>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-61b5f5f79c28421a932707e19048afd75e5ae384.tar.gz

___

Reply to this item at:

  <https://savannah.gnu.org/support/?111002>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110962] pass_all for z/OS

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110962>

 Summary: pass_all for z/OS
   Group: GNU Libtool
   Submitter: None
   Submitted: Tue 28 Nov 2023 05:16:41 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Tue 28 Nov 2023 05:16:41 PM UTC By: Anonymous
Hi, I wanted to submit this patch for z/OS:
https://lists.gnu.org/archive/html/libtool-patches/2023-11/msg8.html

It's a simple patch to add pass_all for opendition (z/OS).

Thanks,
Igor







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110962>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110947] flang: error: unknown argument: '-soname'

[anonymous]

Follow-up Comment #3, sr #110947 (project libtool):

I confirm that the patch works against the latest development branch:

$ libtool --version
libtool (GNU libtool) 2.4.7.4-1ec8f

I just added "flang" in addition to "armflang":


cat < patch.libtool.m4
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..c39ea2f3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4719,6 +4719,12 @@ m4_if([\$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_pic, \$1)='-fPIC'
_LT_TAGVAR(lt_prog_compiler_static, \$1)='-static'
 ;;
+  # flang variants
+  flang* | armflang*)
+   _LT_TAGVAR(lt_prog_compiler_wl, \$1)='-Wl,'
+   _LT_TAGVAR(lt_prog_compiler_pic, \$1)='-fPIC'
+   _LT_TAGVAR(lt_prog_compiler_static, \$1)='-static'
+;;
   # Lahey Fortran 8.1.
   lf95*)
_LT_TAGVAR(lt_prog_compiler_wl, \$1)='-Wl,'
EOF


Building the development branch of libtool with this patch (using
./bootstrap), I get a fixed version, and now see the correct expected
behaviour:

/bin/sh ./libtool  --tag=FC   --mode=link armflang  -g -version-info 0:0:0  -o
libp2.la -rpath /bm/ashterenli/p2/reproducer/reproducer-1.0/_inst/lib
libp2_la-ffun.lo libp2_la-cfun.lo  
libtool: link: armflang -shared  -fPIC  .libs/libp2_la-ffun.o
.libs/libp2_la-cfun.o-g   -Wl,-soname -Wl,libp2.so.0 -o
.libs/libp2.so.0.0.0




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110947] flang: error: unknown argument: '-soname'

[anonymous]

Follow-up Comment #2, sr #110947 (project libtool):

Sorry, a typo -- I got this via autom...@gnu.org.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110947] flang: error: unknown argument: '-soname'

[anonymous]

Follow-up Comment #1, sr #110947 (project libtool):

I got this via autoto...@gnu.org:

Dear Anton,

here is a patch for libtool that Francois Coppens and I submitted to
libtool in February. I think we did something went wrong in the PR
process because it has still not been included... Maybe you can submit
it again to the libtool team, it is not a big change and it is quite
important for us too to have this patch included.

best,

Anthony


$ git diff 1ec8fa28dcb29500d485c136db28315671ec4c3b
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..df1a7860 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4719,6 +4719,12 @@ m4_if([$1], [CXX], [
   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
   _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+  # ARM flang
+  armflang*)
+_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+;;
  # Lahey Fortran 8.1.
  lf95*)
   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110947] flang: error: unknown argument: '-soname'

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110947>

 Summary: flang: error: unknown argument: '-soname'
   Group: GNU Libtool
   Submitter: None
   Submitted: Sun 22 Oct 2023 12:02:06 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: shterenli...@par-tec.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Sun 22 Oct 2023 12:02:06 PM UTC By: Anonymous
It seems flang (and armflang) are not handled correctly by libtool.

In a simple project (reproducer attached) I get:

/bin/sh ./libtool  --tag=FC   --mode=link armflang  -g -version-info 0:0:0  -o
libp2.la -rpath /bm/ashterenli/p2/reproducer/reproducer-1.0/_inst/lib
libp2_la-ffun.lo libp2_la-cfun.lo  
libtool: link: armflang -shared   .libs/libp2_la-ffun.o .libs/libp2_la-cfun.o 
   -g   -soname libp2.so.0 -o .libs/libp2.so.0.0.0
armflang: error: unknown argument: '-soname'


Note that "-Wl" is mising.

If gfortran is used instead, I get:

/bin/sh ./libtool  --tag=FC   --mode=link gfortran  -g -O2 -version-info 0:0:0
 -o libp2.la -rpath /bm/ashterenli/p2/reproducer/reproducer-1.0/_inst/lib
libp2_la-ffun.lo libp2_la-cfun.lo  
libtool: link: gfortran -shared  -fPIC  .libs/libp2_la-ffun.o
.libs/libp2_la-cfun.o-g -O2   -Wl,-soname -Wl,libp2.so.0 -o
.libs/libp2.so.0.0.0

Note that "-Wl" now appears correctly.










___
File Attachments:


---
Date: Sun 22 Oct 2023 12:02:06 PM UTC  Name: reproducer.tar.gz  Size: 1KiB  
By: None

<http://savannah.gnu.org/support/download.php?file_id=55265>

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110947>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110925] libtool 2.4.7.4-1ec8f-dirty infinite loop on unknown (out of order) argument

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110925>

 Summary: libtool 2.4.7.4-1ec8f-dirty infinite loop on unknown
(out of order) argument
   Group: GNU Libtool
   Submitter: None
   Submitted: Sun 20 Aug 2023 08:15:20 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: cont...@kara-online.net
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Sun 20 Aug 2023 08:15:20 AM UTC By: Anonymous
Libtool 2.4.7.4-1ec8f-dirty enters an infinite loop in func_parse_options()
when an invalid argument (with a parameter) is given after a valid argument.
This is due to the variable $func_run_hooks_result not being cleared between
iterations, coupled with the fall-through logic of case "--*=*".

Suggest adding:
func_unset func_run_hooks_result
above:
func_run_hooks func_parse_options ${1+"$@"}
in func_parse_options().







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110925>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110796] libtool-2.4.7/build-aux/git-version-gen uses kind of a hack

[anonymous]

URL:
  <https://savannah.gnu.org/support/?110796>

 Summary: libtool-2.4.7/build-aux/git-version-gen uses kind of
a hack
 Project: GNU Libtool
   Submitter: None
   Submitted: Wed 07 Dec 2022 11:26:55 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: peter_dyba...@web.de
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS


___

Follow-up Comments:


---
Date: Wed 07 Dec 2022 11:26:55 PM UTC By: Anonymous
Hello!

On an elderly Mac with PPC Mac OS X 10.4.11, Tiger, this was reported:

expr: brackets ([ ]) not balanced

It comes from this line

   76   year=`expr "$scriptversion" : '\([^-]*\)'`

On two more up-to-date intel Macs expr worked correctly. I can make another
test on PPC Mac OS X 10.5.8, Leopard.

--

Pete







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110796>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110550] File expected to be at /usr/bin/file, isn't on ChromeOS

[anonymous]

URL:
  

 Summary: File expected to be at /usr/bin/file, isn't on
ChromeOS
 Project: GNU Libtool
Submitted by: None
Submitted on: Sun 17 Oct 2021 04:47:52 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

I'm a developer for Chromebrew, a package manager for ChromeOS.

We've had a problem with most all configure scripts: `file` is expected at
`/usr/bin/file`, but ChromeOS doesn't ship with `file`, so we have to provide
it at `/usr/local/bin/file`. `./configure` scripts generated with `autoconf`
are unaware of this and, instead of looking for the location of `file`, raise
an error:

./configure: line 6712: /usr/bin/file: No such file or directory

This particular error is an example from the latest version of `libsigsegv`

I thought this was an `autoconf` bug, hence the bug report filed here
 but as it turns out, this
is trickling down from `libtool`, specifically the files `ltmain.sh` and
`libtool.m4`

Autoconf and libtool are both at latest versions (2.71 and 2.4.6
respectively)

As I've never reported a bug of this type, I don't know what other information
would be helpful (logs, etc.), so please don't hesitate to let me know.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers

[anonymous]

URL:
  

 Summary: Do not override user's LD_LIBRARY_PATH in generated
ltmain.sh for the build dir wrappers
 Project: GNU Libtool
Submitted by: None
Submitted on: Sat 13 Jul 2019 09:50:51 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

ltmain.sh now (at least in Ubuntu 18.04) overrides the LD_LIBRARY_PATH with a
system library path, thus forcing the system libs over the user's custom path
installed ones. 

I fixed this in TCE build by patching ltmain.sh in our build script generator
script: 

https://github.com/cpc/tce/commit/820fe4475f65b38f4ec6c7013d1ddfe4510058c0#diff-36fd0e6bb489c013aa25e9a5fd4467a2




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


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

[sr #109514] ltmain.sh: [_MSC_VER] should be [_WIN32] in one place

[anonymous]

URL:
  

 Summary: ltmain.sh: [_MSC_VER] should be [_WIN32] in one
place
 Project: GNU Libtool
Submitted by: None
Submitted on: Mon 04 Jun 2018 02:21:41 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

diff:

 #include 
 #include 
-#ifdef _MSC_VER
+#if defined (_WIN32) && !defined (__GNUC__)
 # include 
 # include 
 # include 
 #else
 # include 
 # include 
 # ifdef __CYGWIN__
 #  include 
 # endif
 #endif

The reason is that there are much more compilers for win32 than the
proprietary MSVC. All I'm aware of that are not GCC "based" need process.h
instead of unistd.h.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


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

[sr #108637] libtool adds -rpath to staging directory

[anonymous]

Follow-up Comment #2, sr #108637 (project libtool):

As pointed out by Roumen Petrov, overriding the sys_lib_dlsearch_path_spec
variable gets the behavior I want. In specific, passing
lt_cv_sys_lib_dlsearch_path_spec=... with a list of paths to ./configure gets
them excluded from the default -rpath.

http://lists.gnu.org/archive/html/libtool/2014-08/msg4.html

More follow up on this issue here:

http://lists.gnu.org/archive/html/libtool/2014-12/msg3.html

I think this one can be closed now.


___

Reply to this item at:

  http://savannah.gnu.org/support/?108637

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[sr #108637] libtool adds -rpath to staging directory

[anonymous]

Follow-up Comment #1, sr #108637 (project libtool):

Small correction, step #4 should read Build dbus.

If someone could confirm this is indeed a bug and whether there's a good
workaround for it that would be great.

Thinking about it, my impression is that bintest should actually be a wrapper
shell script with the actual binary under .libs/bintest and make install
should possibly relink it without the rpath to the staging directory...

I'd be happy to contribute code, but I'd need some pointers on where the issue
is and what would be an acceptable way to fix this.

Thanks!
Filipe


___

Reply to this item at:

  http://savannah.gnu.org/support/?108637

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[sr #108637] libtool adds -rpath to staging directory

[anonymous]

URL:
  http://savannah.gnu.org/support/?108637

 Summary: libtool adds -rpath to staging directory
 Project: GNU Libtool
Submitted by: None
Submitted on: Tue 19 Aug 2014 11:30:33 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: filbran...@google.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Hi,

I'm trying to link binaries to libraries that are not installed on the system,
but just unpacked to a staging directory.

Consider this (real) example:

1) Build expat with --libdir=/usr/lib/${platform}
2) Install expat with make install DESTDIR=${stagedir}
3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it will find
expat now, and -rpath /usr/lib/${platform} where it will find expat at real
runtime when both are installed.
4) Build expat

The problem is that ${stagedir} is leaking and the resulting dbus-daemon gets
both /usr/lib/${platform} *and* ${stagedir}/usr/lib/${platform} added to
it...

I tried working around it by passing --with-sysroot=${stagedir} to the dbus
configure, but unfortunately that didn't work...

I wrote a small reproducer that seems to illustrate the issue, I tried it with
latest libtool from git (commit ac180507c123469d0fe9b25437d459af24b3f789) and
I still have the same problem.

$ libtool_rpath/reproduce.sh
...
=== RPATH of bintest:
 0x000f (RPATH)  Library rpath:
[/path/to/libtool_rpath/destdir/usr/lib/platform:/usr/lib/platform]

Do you have a suggestion of something I could do to accomplish what I'm trying
to accomplish?

Is this a libtool bug?

Any suggestions of workarounds?

Thanks!
Filipe




___

File Attachments:


---
Date: Tue 19 Aug 2014 11:30:33 PM UTC  Name: libtool_rpath.tgz  Size: 912B  
By: None
Script to reproduce this bug.
http://savannah.gnu.org/support/download.php?file_id=31921

___

Reply to this item at:

  http://savannah.gnu.org/support/?108637

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[sr #107959] Libtool generates invalid .def files

[anonymous]

Additional Item Attachment, sr #107959 (project libtool):

File name: 01-def-syntax.patchSize:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/support/?107959

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

[sr #106790] Version 2.2.6 shaded native option -shared of ld

[anonymous]

Follow-up Comment #3, sr #106790 (project libtool):

Thanks for explanation.
And one question left.
Can I disable static libraries building only for modules, without
--disable-static global using?

___

Reply to this item at:

  http://savannah.gnu.org/support/?106790

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[sr #106790] Version 2.2.6 shaded native option -shared of ld

[anonymous]

URL:
  http://savannah.gnu.org/support/?106790

 Summary: Version 2.2.6 shaded native option -shared of ld
 Project: GNU Libtool
Submitted by: None
Submitted on: Wed 27 May 2009 09:38:18 AM UTC
Category: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: rom...@oscada.org.ua
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Project's which build many applets (shared modules) not builded simply
without -shared option to ld.
Into version 1.5 used strings for applets build:

oscd_modul_PROGRAMS = daq_JavaLikeCalc.so
AM_LDFLAGS= -shared -module

But into 2.2.6 it not work by appear self libtool option -shared.

Standard libraries build mechanism too difficult for build simple applets and
for company build static library.

How build applets with libtool 2.2.6?




___

Reply to this item at:

  http://savannah.gnu.org/support/?106790

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[sr #106790] Version 2.2.6 shaded native option -shared of ld

[anonymous]

Follow-up Comment #1, sr #106790 (project libtool):

Sorry, not applets. Plugins build.

___

Reply to this item at:

  http://savannah.gnu.org/support/?106790

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[sr #106237] Newbie: libltdl not matching #include ltdl.h

[anonymous]

URL:
  http://savannah.gnu.org/support/?106237

 Summary: Newbie:  libltdl not matching #include ltdl.h
 Project: GNU Libtool
Submitted by: None
Submitted on: Saturday 01/26/2008 at 22:53 UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

OS:
Current kubuntu Linux with package libltdl3 loaded
[1.5.24-lubuntu; /usr/lib/libltdl.so.3.1.5, et al]

SYMPTOM:
 undefined reference to `lt_preloaded_symbols'

USAGE:
//
 #include ltdl.h 

 iptr
 init_foreign_loading() 
 {
   LTDL_SET_PRELOADED_SYMBOLS();
   return( (iptr)lt_dlinit() ) ;
 }
//

CCFLAGS: gcc  -g -O2 -DNDEBUG -O3 -Wall -DDYNAMIC_LOADING_SUPPORTED 
-rdynamic  -o

LOADFLAGS:
 -lgmp -lm -ldl -lltdl

INFO:
/usr/lib nm libltdl.a |grep -i preload
0028 b default_preloaded_symbols
2200 T lt_dlpreload
0240 T lt_dlpreload_default
002c b preloaded_symbols

NOTE: lack of 'lt_preloaded_symbols' def

My conclusion is that the include does not match the library.

It has been some years since I wrote C code, so I am pretty clueless.  This
MUST be pilot error on my part.  Can somebody help me out here?

Thanks a bunch,
-Ken [dot] Dickey [at] Whidbey [dot] Com




___

Reply to this item at:

  http://savannah.gnu.org/support/?106237

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[patch #6104] reduce space complexity for piecewise linking

[anonymous]

URL:
  http://savannah.gnu.org/patch/?6104

 Summary: reduce space complexity for piecewise linking
 Project: GNU Libtool
Submitted by: None
Submitted on: Wednesday 07/18/2007 at 00:25 UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The space complexity of the piecewise linking code is O(n^2) because it keeps
all the intermediate object files. On big projects, this can quickly eat up
gigabytes of hard disk space unneccessarily. So I propose the attached
minimally intrusive patch which reduces the complexity to O(n).

Regards,

Isidor



___

File Attachments:


---
Date: Wednesday 07/18/2007 at 00:25 UTC  Name: libtool-on.patch  Size: 1004B 
 By: None

http://savannah.gnu.org/patch/download.php?file_id=13380

___

Reply to this item at:

  http://savannah.gnu.org/patch/?6104

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[sr #105489] --whole-archive doesn't work on OSX

[anonymous]

Follow-up Comment #1, sr #105489 (project libtool):

Mac OS/X does have a way to turn off the all_load option. The (undocumented)
option is -noall_load. I have this from Apple compiler developers.

___

Reply to this item at:

  http://savannah.gnu.org/support/?func=detailitemitem_id=105489

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[sr #105489] --whole-archive doesn't work on OSX

[anonymous]

URL:
  http://savannah.gnu.org/support/?func=detailitemitem_id=105489

 Summary: --whole-archive doesn't work on OSX
 Project: GNU Libtool
Submitted by: None
Submitted on: Wednesday 08/02/2006 at 01:21 UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
Operating System: Mac OS

___

Details:

(apologies if this is the wrong place to file bugs, I could find the
bugtracker).

This bug tested on:
Darwin bioeng21.bioeng.auckland.ac.nz 8.7.0 Darwin Kernel Version 8.7.0: Fri
May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power Macintosh
powerpc

It seems that recent versions of libtool don't support the --whole-archive on
MacOSX. This causes the --whole-archive flag to be passed to gcc (which seems
to be silently ignored on OSX), resulting in a link which doesn't really
contain the whole archive.
For example:

/bin/sh ./libtool --tag=CXX --mode=link g++  -g -O2   -o cellml_corba_server
-lxml2 -lomniORB4 -lomnithread --whole-archive cellml_corba_server-Main.o
./libcellml_context.la ./libcellml_context_corba.la ./libcellml.la
./libcellml_corba.la ./libCORBASupport.la ./libltdlc.la
g++ -g -O2 -o .libs/cellml_corba_server --whole-archive
cellml_corba_server-Main.o -Wl,-bind_at_load  /usr/lib/libxml2.dylib
-lpthread -lz /usr/lib/libiconv.dylib -lm -lomniORB4 -lomnithread
./.libs/libcellml_context.dylib ./.libs/libcellml_context_corba.dylib
./.libs/libcellml.dylib ./.libs/libcellml_corba.dylib
./.libs/libCORBASupport.a ./.libs/libltdlc.a
creating cellml_corba_server

bioeng21:~/physiome_builds/trees/CellML_DOM_API_OSX cmiss$ nm
.libs/cellml_corba_server |grep gWrapperRepo
bioeng21:~/physiome_builds/trees/CellML_DOM_API_OSX cmiss$ nm
.libs/libCORBASupport.a |grep gWrapperRepo
00ac t __GLOBAL__D__Z18gWrapperRepositoryv
 a __GLOBAL__D__Z18gWrapperRepositoryv.eh
009c t __GLOBAL__I__Z18gWrapperRepositoryv
 a __GLOBAL__I__Z18gWrapperRepositoryv.eh
0190 T __Z18gWrapperRepositoryv
1820 S __Z18gWrapperRepositoryv.eh
1a58 b __ZGVZ18gWrapperRepositoryvE2wr
1a60 b __ZZ18gWrapperRepositoryvE2wr

I understand older libtools gave the -Wl,-all_load flag, which is similar to
--whole-archive on the ld from GNU binutils. However, unlike GNU ld, you
can't turn off all_load for some archives, and leave it on for others, so you
end up messing up the linking of the implicit libraries:
^ioeng21:~/physiome_builds/trees/CellML_DOM_API_OSX cmiss$ g++ -Wl,-all_load
-g -O2 -o .libs/cellml_corba_server --whole-archive
cellml_corba_server-Main.o -Wl,-bind_at_load  /usr/lib/libxml2.dylib
-lpthread -lz /usr/lib/libiconv.dylib -lm -lomniORB4 -lomnithread
./.libs/libcellml_context.dylib ./.libs/libcellml_context_corba.dylib
./.libs/libcellml.dylib ./.libs/libcellml_corba.dylib
./.libs/libCORBASupport.a ./.libs/libltdlc.a
/usr/bin/ld: warning multiple definitions of symbol ___eprintf
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc.a(_eprintf.o) private
external definition of ___eprintf in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libstdc++.dylib(single module)
definition of ___eprintf
/usr/bin/ld: warning multiple definitions of symbol ___divdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc.a(_divdi3.o) private external
definition of ___divdi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_s.dylib(_divdi3_s.o)
definition of ___divdi3
/usr/bin/ld: warning multiple definitions of symbol ___udivdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc.a(_udivdi3.o) private
external definition of ___udivdi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_s.dylib(_udivdi3_s.o)
definition of ___udivdi3
/usr/bin/ld: warning multiple definitions of symbol ___umoddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc.a(_umoddi3.o) private
external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_s.dylib(_umoddi3_s.o)
definition of ___umoddi3
 
(which is presumably why older versions dropped that flag, and caused this
bug).

Unless someone finds a better way, I think the correct solution will have to
be to unarchive the convenience libraries and link the objects manually.







___

Reply to this item at:

  http://savannah.gnu.org/support/?func=detailitemitem_id=105489

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[sr #100410] clean mode wants to remove unknown files

[anonymous]

Additional Item Attachment, sr #100410 (project libtool):

File name: \'¿i╨.åë½Size:0 KB

http://savannah.gnu.org/support/download.php?file_id=10222

___

Reply to this item at:

  http://savannah.gnu.org/support/?func=detailitemitem_id=100410

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[patch #3686] Trivial patch to change sprintf to snprintf in libltdl

[anonymous]

Additional Item Attachment, patch #3686 (project libtool):

File name: bbrun.cSize:4 KB
bigbrother file to change
http://savannah.gnu.org/patch/download.php?item_id=3686item_file_id=4714

___

Reply to this item at:

  http://savannah.gnu.org/patch/?func=detailitemitem_id=3686

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[support #103719] catching unresolved symbols at link time, and template instantiation

[anonymous]

This mail is an automated notification from the support tracker
 of the project: GNU Libtool.




/**/
[support #103719] Full Item Snapshot:

URL: http://savannah.gnu.org/support/?func=detailitemitem_id=103719
Project: GNU Libtool
Submitted by: 0
On: Thu 12/30/2004 at 14:54

Category:  None
Priority:  5 - Normal
Severity:  3 - Ordinary
Resolution:  None
Privacy:  Public
Assigned to:  None
Originator Email:  [EMAIL PROTECTED]
Status:  Open


Summary:  catching unresolved symbols at link time, and template instantiation

Original Submission:  I'm converting to the use of libtool for my C++ libraries.
These libraries tend to have inter-library dependencies.  Libtool does not 
catch when my library has unresolved symbols due to a missing dependency (or 
any other reason).
In my previous build system, I used a prelink stage for checking for 
unresolved symbols and instantiating templates.
For g++, this is about as simple as replacing the '-shared' option with the 
following, as a pre-link before the real link:

-Wl,-defsym,main=0x0,-defsym,MAIN__=0x0

Since it's treated as an executable rather than a library, complete symbol 
checking and template instantiation occur.

I would like to see libtool provide a similar capability, even if only when g++ 
is used.  Without this, it is very difficult to determine missing dependencies 
in a library.

I am currently using libtool 1.5.2












For detailed info, follow this link:
http://savannah.gnu.org/support/?func=detailitemitem_id=103719

___
  Message sent via/by Savannah
  http://savannah.gnu.org/





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