Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3805 closed enhancement (invalid)

Links to libc and libm would be useful

Reported by: haiqu Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

When configuring new software using the familiar ./configure; make; make install regimen, special parameters often have to be passed on the commanline to ensure that certain libraries are detected correctly. In the worst case, if a configure script isn't well written, it can fail to find the required libraries.

We have examples of fixes already implemented in Haiku. libnetwork.so is already symlinked to both libbind.so and libsocket.so which are the names expected on most varieties of Unix.

My suggestion is to add the following additional symlinks:

/boot/system/lib/libroot.so -> /boot/system/lib/libm.so
/boot/system/lib/libroot.so -> /boot/develop/lib/x86/libm.so
/boot/system/lib/libbe.so -> /boot/system/lib/libc.so
/boot/system/lib/libbe.so -> /boot/develop/lib/x86/libc.so

This idea came about after I noticed the Python-3.1a2 configure script test for the presence of a function in libc (and fail to find it) and then later on recognise that I had passed an alternative to this name. i.e. the script was doing things in the wrong order. Nasty indeed unless you're watching the output of configure like a hawk as it scrolls by...

Change History (6)

comment:1 Changed 10 years ago by umccullough

As pointed out several times in the past, software that expects libc or libm during compile are "buggy" and should be fixed instead of hacking. There are even configure checks for this stuff.

The symlinks to libbind and libsocket are NOT for development, and will actually fail if used as such - they are purely for runtime compatibility with BONE.

Not to be a PITA here, but this has definitely been discussed in the past on the mailing list, and I suspect there are already tickets in the system regarding this.

comment:2 Changed 10 years ago by umccullough

Example AC check to help fix the problem:

http://www.freelists.org/post/haiku-development/missing-lm,1

comment:3 Changed 10 years ago by haiqu

[fx: nods in approval of your wisdom]

Suggestion withdrawn. But I sure hate fixing all these broken configure scripts... ;-]

comment:4 Changed 10 years ago by haiqu

Just re-reading the message from Francois you referred to, it appears that both libc and libm code resides in libroot.so on BeOS and Haiku. So if anyone is thinking of doing this, the original suggestion I made isn't right anyhow.

Further comment on links to libsocket and libbind being done for runtime compatibility with BONE: Yes, but those names were used by Be, Inc. originally because that's what the files are called in BSD - which is where the code originated - and everyone uses those locations. So it's done for general compatibility with Unices.

My suggestion above was in the same vein.

comment:5 Changed 10 years ago by axeld

Resolution: invalid
Status: newclosed

The libbind/libsocket links are only in the /system/lib/ directory - new software is not supposed to be linked against them. They are only there for BONE compatibility at runtime.

comment:6 Changed 10 years ago by haiqu

Ok, I see the way that's supposed to work. For logical consistency the link:

/boot/system/lib/libGL.so -> /boot/develop/lib/x86/libglut.so

should probably be removed too.

Note: See TracTickets for help on using tickets.