Michael Saltz wrote:
> I'm trying to link with libm.so.1 instead of libm.so.2, but otherwise
> build my application on Solaris 10. So far, I've not been successful
It's easy:
oxpoly 1028.. cat > xxx.c
void main(){}
oxpoly 1029.. cc -o xxx.1 xxx.c -lm
oxpoly 1030.. elfdump -d xxx.1 | fgrep libm
[0] NEEDED 0x199 libm.so.2
oxpoly 1031..
oxpoly 1031.. cc -o xxx.2 xxx.c /usr/lib/libm.so.1
oxpoly 1032.. elfdump -d xxx.2 | fgrep libm
[0] NEEDED 0x199 libm.so.1
But, be careful. Other dependencies of your application may
need libm.so.2. In fact, libc can reference this dependency as
a filtee. You'll end up by getting both versions being brought
into the same process:
oxpoly 1071.. ldd xxx.2
libm.so.1 => /lib/libm.so.1
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
References that an object might expect to be resolved from .2
can be resolved against .1. For most interfaces I don't think
this is a problem, but I seem to recall one or more interfaces
changing their signature, which is why the major number was
bumped. A mis-binding of a caller to the definition may be
problematic.
Why do you want libm.so.1?
--
Rod.
