[patch #9999] Fix --preserve-dup-deps flag not to strip some duplicates

[Julien ÉLIE]

Follow-up Comment #1, patch # (group libtool):

FWIW, the patch was locally applied to INN in 2020, and there hasn't been any
build problem since then.  Building INN with libtool otherwise failed with
unresolved circular dependencies, even with the use of *--preserve-dup-deps*.

https://github.com/InterNetNews/inn/commit/e715e957fe7db5acc9ec1beaa9abb2ba120c287b#diff-6858ef1035c11e53d6a00ef454d86e2eab93aae2fc7f83f201069946e916c643


I believe it would be useful to fix it upstream too.  There even was a comment
in _ltmain.sh_ noting that the current code is broken and should be fixed,
along with the fix in a commented line:


# FIXME: Pedantically, this is the right thing to do, so
#that some nasty dependency loop isn't accidentally
#broken:
#new_libs="$deplib $new_libs"


The patch basically uses the right expected logic for *--preserve-dup-deps*.


___

Reply to this item at:

  

___
Message posté via Savannah
https://savannah.gnu.org/

Installation of libtool-2.4.7 from source

[Carissa Chen]

Hello,

I have installed libtool-2.4.7 from source as I require it for the latest 
Singularity version. However when I try to run libtoolize, it gives this error.


libtoolize:   error: $pkgauxdir is not a directory: 
'/usr/local/share/libtool/build-aux'

I’m not quite familiar with source installation, is there a way to change the 
path to my local path /usr/opt/libtool-2.4.7/build-aux?

Any help would be greatly appreciated!

CARISSA CHEN | PhD Student in Computational Biology
Computational Systems Biology Unit
Children’s Medical Research Institute
Faculty of Medicine & Health | THE UNIVERSITY OF SYDNEY
Email cc...@cmri.org.au   | Github 
https://github.com/carissaynchen

Re: [PATCH] Fix Wstrict-prototypes warnings

[Peter Kokot]

On Tue, 16 Apr 2024 at 19:56, Ileana Dumitrescu
 wrote:
>
> Thank you for the patch. Diagnosing the test errors is not so easy
> without more information. Could you tell me which tests failed for you,
> and which ones you fixed with the addition of this patch? Also, which
> libtool and compiler version you are using?

Consider creating a minimalistic configure.ac:

AC_PREREQ([2.71])
AC_INIT([ExampleProject], [1.0.0])
AC_PROG_CC
AC_MSG_NOTICE([Configuring Libtool])
LT_INIT
AC_OUTPUT

Then run "autoreconf -i" to create a configure script.

And then "./configure CFLAGS=-Werror=strict-prototypes"

In the config.log file there will be error similar to this:
conftest.c:10:5: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
10 | int main(){nm_test_var='a';nm_test_func();return(0);}
| ^~~~
cc1: some warnings being treated as errors

Some errors are related to Autoconf, which has fixed most of these in
2.72 already. And this patch (hopefully) fixes most if not all those
related to Libtool.

Libtool version: 2.4.7
Compiler: GCC 13.2

Issue is that some compilers might enable strict-prototypes by default
in future versions.

-- 
Peter Kokot

ld scripts and libltdl

[Madhu]

I'm using a program that uses libltdl (from libtool) to wrap calls to
dlopen (e.g. lt_dlopenext) and dlsym and it is utterly unable to dlopen
"standard" shared libraries.

Gentoo (probably following upstream glibc) has been putting linker
scripts where shared libraries were orignially expected.

```
$ cat /usr/lib64/libm.so
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libm.so.6  AS_NEEDED ( /lib64/libmvec.so.1 ) )
```

So a call to lt_dlopenext("libm"), with ltdl compiled with
-DLT_DEBUG_LOADERS, produces output like this (but lt_dlerror only
reports "File not found")

```
try_dlopen (libm, .la)
tryall_dlopen (libm.a, lt_preopen)
Calling lt_preopen->module_open (libm.a)
  Result: Failed
  Error message << file not found >>
try_dlopen (libm, .so)
tryall_dlopen (libm.a, lt_preopen)
Calling lt_preopen->module_open (libm.a)
  Result: Failed
  Error message << file not found >>
tryall_dlopen (/usr/lib64/libm.so, (ALL))
Calling lt_dlopen->module_open (/usr/lib64/libm.so)
  Result: Failed
  Error message << /usr/lib64/libm.so: invalid ELF header >>
Calling lt_preopen->module_open (/usr/lib64/libm.so)
  Result: Failed
  Error message << file not found >>
```

Only a call to lt_dlopen with the full path "/lib64/libm.so.6" would
work.  But the library I'm using only exposes lt_dlopenext.

Perhaps ltdl should parse the linker scripts and dlopen the real dll?

--- 
Regards,
Madhu