Re: [PATCH] Dynamic Linking fixes for NetBSD/amd64

["Lorenz Minder" <lminder@gmx.net>]

Hi Bill,

BA:
> On Thu, Sep 03, 2009 at 08:16:17AM +0200, Lorenz Minder wrote:
> > Hi,
> > 
> > I need the following patches to build and run PARI on NetBSD/amd64 with
> > dynamic libraries.  The first one sets the -fPIC flag on compile, the
> 
> Hello Lorenz,
> Your first part of your patch looks wrong somehow, as if you were working
> around some breakage of Configure. What does config/arch-osname report on
> this
> machine ?  For example, -fPIC should be already set if arch-osname report
> this
> is a 64bit x86_64 machine.

I think you're right.  The problem is that on NetBSD that architecture is
reported as "amd64", not "x86_64".  I have attached a modified patch.

> > second patch makes it possible to specify additional DLLDFLAGS on the
> > command line to ./Configure.  This is useful because NetBSD's packages
> > are by default stored in /usr/pkg, and the dynamic linker does not know
> > about that location; so you want to supply an -rpath option to link
> > against GMP or readline (unless you compile those by hand as well).
> 
> This patch is correct, but this seems like an odd system: if package
> belong in
> /usr/pkg/lib, then why is not the dynamic loader configured to look there
> ?

It is possible to set LD_LIBRARY_PATH or adjust ld.so.conf to look
in /usr/pkg/lib for libraries, but the NetBSD folks discourage doing
such things, see

   http://www.netbsd.org/docs/elf.html

As far as I know, it is indeed common practice not to create an
ld.so.conf file on NetBSD.  What they do for the pkgsrc packages
collection is to link every single executable with the right rpath.

I have now tried to run the tests on this system.  Right now I'm stuck at
the ellsea test; this test uses a huge amount of memory (probably more
than 2GB) until it is eventually killed by the kernel because the
system is running out of swap.  Is anything known about this problem?
Does it happen on other systems too?

(I just tried this test on Mac OS X, and it doesn't work either.  It
fails differently, though: instead of running out of memory it reportedly
produces wrong output.)

Another minor problem on NetBSD is that some times reported by 'make
bench' are negative, see the attached bench_out file.

Best,
--Lorenz
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Attachment: dylld_netbsd1.patch
Description: Binary data

Attachment: bench_out
Description: Binary data