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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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.
 --=_yEQegd6KE+J0RR5NTU8CY9iUdk+bjG6u
 
 gnats-bugs@ got dropped from cc list
 
 --=_yEQegd6KE+J0RR5NTU8CY9iUdk+bjG6u
 Content-Type: message/rfc822
 Content-Disposition: inline
 
 Date: Fri, 10 Mar 2023 12:21:22 +0100
 From: Jan-Benedict Glaw <jbglaw%lug-owl.de@localhost>
 To: port-amd64-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 	netbsd-bugs%netbsd.org@localhost
 Subject: Re: port-amd64/57265: Cross-build broken from Linux amd64 to NetBSD
 	amd64
 Message-ID: <20230310112122.bznozwomag5kywz4%lug-owl.de@localhost>
 In-Reply-To: <20230309181002.C7FC21A923A%mollari.NetBSD.org@localhost>
 References: <pr-port-amd64-57265%gnats.netbsd.org@localhost>
 	<20230309160510.3E55C1A923A%mollari.NetBSD.org@localhost>
 	<20230309181002.C7FC21A923A%mollari.NetBSD.org@localhost>
 MIME-Version: 1.0
 Content-Type: multipart/signed; micalg=pgp-sha1;
 	protocol="application/pgp-signature"; boundary="cnot5engxscipb6p"
 Content-Disposition: inline
 
 
 --cnot5engxscipb6p
 Content-Type: text/plain; charset=utf-8
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 Hi!
 
 On Thu, 2023-03-09 18:10:02 +0000, Jan-Benedict Glaw <jbglaw%lug-owl.de@localhost> wr=
 ote:
 >  >  ++ 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 ld.so 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 `ld.so`
 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 ld.so .  The more correct
 assignment would be
 
     export LD_LIBRARY_PATH=3D"/my/lib{LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
 
 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 =
 *pathstr)
 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
 well:
 
      LD_LIBRARY_PATH  A colon separated list of directories, overriding the
                       default search path for shared libraries.
 
 
 Thanks,
   Jan-Benedict
 
 --=20
 
 --cnot5engxscipb6p
 Content-Type: application/pgp-signature; name="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQQlDTvPcScNjKREqWEdvV51g5nhuwUCZAsSsAAKCRAdvV51g5nh
 u58pAJoD23Og8U4xUMHVzHr3LbRphQDBzQCffy8iwZIozFKBZvTTO20CgUmBGeQ=
 =PXqx
 -----END PGP SIGNATURE-----
 
 --cnot5engxscipb6p--
 
 --=_yEQegd6KE+J0RR5NTU8CY9iUdk+bjG6u--