Subject: Re: Libtool on NetBSD/ELF
To: Steinar Hamre <steinarh@stud.fim.ntnu.no>
From: Nick Hudson <nick@nthcliff.demon.co.uk>
List: tech-pkg
Date: 10/02/2000 13:40:06
It looks as though you are using the 1.3.5 distribution which does have
problems for NetBSD.
Steinar Hamre wrote:
> Ok, everyone hates libtool for always beeing so wrong. But we still
> have to fix it. libtool -module on netbsd/elf creates an 'ar'-archive,
> and *wow* that does not work with dlopen(). So I've tried fixing
> libtool on netbsd/elf a little bit. It would be very nice if somebody
> told me if I'm doing anything awfully wrong before i send this to the
> libtool maintainers.
>
> First,echo __ELF__ | $CC -E - | grep __ELF__is true if the the
> toolcain is *not* elf. So the first test was inversed.
This is fixed in the pkgsrc libtool.
> secondly there is no problem making and using a library named `u'
> need_lib_prefix=no
> need_version=no
>
> LD_LIBRARY_PATH overrides the binary's RPATH
> shlibpath_overrides_runpath=yes
This is in the libtool cvs repository along with hardcode_into_libs=yes
> file_magic seems to be the most sensible deplibs_check_method. (better
> than unknown, anyway)
This is in pkgsrc and cvs libtool.
> The (seriosly misnamed) version_type `linux' seems to be the most
> sensible one. It's used by most elf and ecoff platforms. The only real
> alternative is `freebsd-elf'. The difference is: `linux' uses 3-digit
> versioning libfoo.so.$major.$age.$minor (major=$current-$age) whereas
> `freebsd-elf' uses 1-digit versioning libfoo.so.$current
I've not look at this one...
> $ libtool --mode=link gcc -version-info 6:1:4 [...] will create
> libfoo.so.2.4.1 (soname libfoo.so.2) using `version_type=linux'
> libfoo.so.6 (soname libfoo.so.6) using `version_type=freebsd-elf'
I presume the 2 in a typo?!?
Nick