bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ncurses-6.2-20200817: Error creating shared libraries on NetBSD 9.0


From: Thomas Dickey
Subject: Re: ncurses-6.2-20200817: Error creating shared libraries on NetBSD 9.0
Date: Sat, 22 Aug 2020 14:09:18 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Aug 21, 2020 at 04:01:03AM -0400, Thomas Dickey wrote:
> On Fri, Aug 21, 2020 at 01:09:24AM +0000, Rajeev V. Pillai wrote:
> >  On Friday, 21 August 2020, 05:27:51 GMT+5:30, Thomas Dickey 
> > <dickey@his.com> wrote:
> > 
> > 
> > > sure - it's a problem with the compiler's linker script.
> > 
> > gcc-7.5.0 NetBSD 9.0_STABLE std compiler
> 
> this is the only relevant one (something to verify when I've time to
> compile that package).

As it turns out, I was able to use pkgin (otherwise I'd have followed up
after a few weeks).

However...

Most of my machines are new-installs, virtual machines, to eliminate the
problems in upgrade procedures.  NetBSD is no exception here on either point.

NetBSD 9's packages for gcc all require a library which was last provided in
NetBSD 7.  It's been a known issue for a few years (as seen in reports from
NetBSD 8.  I keep the media, though, and did an install for a throwaway
NetBSD 7.

Then I installed gcc 7, 8, 9 and 10, to investigate.  My normal build worked,
and (not being as hurried on the weekend), I noticed that the chunk which was
suggested for change is in the case where rpath isn't used.

Now... I use rpath to work around a flaw in NetBSD's pkgsrc.  The packagers
do it their own way, of course, but ultimately they've not taken into account
developers installing things which are neither the base system nor pkgsrc.

Since I'm not going to require others to make changes to the system's search
path for shared libraries, putting things into /usr/local on NetBSD leads
straight to rpath as a solution.

This week's bug report notes that passing -Bsharable to the linker doesn't
work as well as using gcc's -shared option.  Using the -v option, I can see
that it uses different objects for the runtime initialization.

        /usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.1.0/crtbeginS.o
        /usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.1.0/crtendS.o

versus (not working):

        /usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.1.0/crtbegin.o
        /usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.1.0/crtend.o

Interestingly enough, the change which produced this difference dates back
to October 1999.  The changelog mentions other (more important) issues
related to CF_SHARED_OPTS.  This part was a patch from Bernd Ernesti,
which I summarized (in aclocal.m4) as

   changes to build on NetBSD with elf vs a.out

and in my-autoconf as

   treat netbsd differently from openbsd/freebsd (from patch).

In short, the difference has been there a while.  Perhaps the compiler
(or supporting objects) changed over the past 21 years, or perhaps most
developers use rpath.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]