Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Apr 2024 23:49:48 +0000
From:      Brooks Davis <brooks@freebsd.org>
To:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        freebsd-arch@freebsd.org, Michael Dexter <editor@callfortesting.org>
Subject:   Re: RFC: linking with --no-undefined-version
Message-ID:  <ZiGxnBxQbauPY2zr@spindle.one-eyed-alien.net>
In-Reply-To: <ZiGwXzN3QBBBtcRX@troutmask.apl.washington.edu>
References:  <ZiGuN-ML65sN2shW@spindle.one-eyed-alien.net> <ZiGwXzN3QBBBtcRX@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 18, 2024 at 04:44:31PM -0700, Steve Kargl wrote:
> On Thu, Apr 18, 2024 at 11:35:19PM +0000, Brooks Davis wrote:
> > As of LLVM 16, lld default to --no-undefined-version which means that if
> > a symbol is listed in the symbol version map it must be present or lld
> > will fail to link.  This is good because it prevents that accidental loss
> > of symbols which breaks our ABI compatibility.  Unfortunately, it's
> > somewhat complicating because our symbol version maps may vary
> > per-architecture or based on options.  As a result we added
> > --undefined-version to LDFLAGS.
> > 
> 
> Just to be clear, does this extend into /usr/ports?  I only have 3020 *.so  
> in /usr/local/lib.  I can image that some software package may have
> missing symbols.

Just the base system and things that use bmake infrastructure from base
(e.g., programs that got kicked out of base like ftpd), but dim@ already
fixed lots of symbol files in ports so I don't expect major issues.

-- Brooks



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZiGxnBxQbauPY2zr>