NetBSD-Bugs archive

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

Re: port-amd64/57265: Cross-build broken from Linux amd64 to NetBSD amd64

The following reply was made to PR port-amd64/57265; it has been noted by GNATS.

From: Taylor R Campbell <>
Subject: Re: port-amd64/57265: Cross-build broken from Linux amd64 to NetBSD amd64
Date: Wed, 15 Mar 2023 11:30:44 +0000

 This is a multi-part message in MIME format.
 gnats-bugs@ got dropped from cc list
 Content-Type: message/rfc822
 Content-Disposition: inline
 Date: Fri, 10 Mar 2023 12:21:22 +0100
 From: Jan-Benedict Glaw <>
 Subject: Re: port-amd64/57265: Cross-build broken from Linux amd64 to NetBSD
 Message-ID: <>
 In-Reply-To: <>
 References: <>
 MIME-Version: 1.0
 Content-Type: multipart/signed; micalg=pgp-sha1;
 	protocol="application/pgp-signature"; boundary="cnot5engxscipb6p"
 Content-Disposition: inline
 Content-Type: text/plain; charset=utf-8
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 On Thu, 2023-03-09 18:10:02 +0000, Jan-Benedict Glaw <> wr=
 >  >  ++ export LD_LIBRARY_PATH=3D3D/usr/lib/gcc-snapshot/lib:
 >  >  ++ LD_LIBRARY_PATH=3D3D/usr/lib/gcc-snapshot/lib:
 >  > =3D20
 >  >  Is that in your build environment?  What happens if you remove it?
 > =20
 >  It is!  That's from a little to choose between different compilers
 >  (ie. a recent GCC snapshot, the "usual" (older) system GCC, some CLANG
 >  versions.  But that LD_LIBRARY_PATH should in no way enable to
 >  pull in some libz (that's a guess) from the destdir, should it?
 > =20
 >    Just started a build using the sytem compiler (not setting
 >  anything). I wonder (read: hope!) that the empty path component
 >  doesn't wrongly resolve to "." ...  (If the next build succeeds, my
 >  next test would be LD_LIBRARY_PATH=3D"/does_not_exist:"...)
 Turns out: `bash` has the documented feature of treating an empty path
 component in `$PATH` as the current directory---and GNU libc's ``
 does the same for `$LD_LIBRARY_PATH`. So ... this ticket can be
 closed, not having an trailing colon is the fix here, it's _not_ a
 NetBSD issue at all. I'm sorry!  OTOH, I'll continue to inquire the
 Debian Security team if this is desired behavior or a CVE-worthy bug.
   I guess that there are quite some place where people assign $PATH
 and $LD_LIBRARY_PATH like this:
     export LD_LIBRARY_PATH=3D"/my/lib:${LD_LIBRARY_PATH}"
 which triggers this issue, at least for GNU .  The more correct
 assignment would be
 which is more clumpsy, but doesn't leave you deadly wounded...
   It seems NetBSD's ld.elf_so does do the same:
 197 void
 198 _rtld_add_paths(const char *execname, Search_Path **path_p, const char =
 199 {
 205         if (pathstr[0] =3D=3D ':') {
 206                 /*
 207                  * Leading colon means append to current path
 208                  */
 209                 while ((*path_p) !=3D NULL)
 210                         path_p =3D &(*path_p)->sp_next;
 211                 pathstr++;
 212         }
 The man page does not mention this somewhat surprising behavior as
      LD_LIBRARY_PATH  A colon separated list of directories, overriding the
                       default search path for shared libraries.
 Content-Type: application/pgp-signature; name="signature.asc"

Home | Main Index | Thread Index | Old Index