On Thu, 21 Aug 2003, Riccardo Mottola wrote:

> I still am in doubt if the error here is a NetBSD culprit, a NetBSD/m68k
> particular problem or a gnustep configure problem.

> in fact the error I see in config.log is:
> configure:3809: checking whether objc has thread support
> configure:3840: gcc -o conftest -O2 -x objective-c -I.  -I/usr/pkg/include
> -I/usr/GNUstep/System/Library/Headers
> -L/usr/GNUstep/System/Library/Libraries -fgnu-runtime   -I/usr/pkg/include
> conftest.c -lobjc  -R/usr/pkg/lib -L/usr/pkg/lib -lpthread  >&5
> <snip>
>
> configure:3845: ./conftest
> Shared object "libpthread.so.20" not found

The problem is that the run-path is not being inserted into the
"/.conftest" binary, as the "-R" option is ignored by gcc 2.95.3.
The latest automake + libtool may convert that to "-Wl,-R" if gcc is
detected (unless it's a custom macro), but an easy work-around is to
set LD_RUN_PATH='/usr/pkg/lib:/usr/X11R6/lib' in your environment
before configuring and building.

The reason the problem goes unnoticed on platforms besides NetBSD, is
that those "other" platforms have a system global search path, invoked
at run-time, which happens to coincide with the average user's
requirements. This is similar to setting LD_SEARCH_PATH on NetBSD.
Setting a policy of requiring the run-path to be set in the binary, as
NetBSD as done, shifts the burden to correctly calculate the run-path
from the user, to the developer or package builder.

Frederick