Date: Sat, 19 Mar 2005 06:08:29 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Scott Long <scottl@samsco.org> Cc: Warner Losh <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h Message-ID: <20050318190828.GC30813@cirb503493.alcatel.com.au> In-Reply-To: <423A8DC5.5010006@samsco.org> References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> <423A8B51.3010609@portaone.com> <423A8DC5.5010006@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2005-Mar-18 01:13:57 -0700, Scott Long wrote: >No, I think that what he's worried about is that you have port foo that >generates a library called libfoo.so.1, and that library is linked >against libm.so.2. You then have port bar that generates a binary >linked against libfoo.so.1 and libm.so.2. Now lets say that libm.so.2 >gets bumped to libm.so.3, and you also rebuild port bar. Now bar is >linked to libfoo.so.1 and libm.so.3, but libfoo.so.1 is still linked >against libm.so.2; Is it worthwhile checking (and warning) about this condition? Possible options include: 1) ld-elf.so learning that a .so is make up of a name and a version number and whinging if an executable attempts to load two shared libraries with the same name and different versions. 2) ld(1) whinging (and failing) if the shared libraries on the command line would result in the final executable being linked against two different versions of a shared library. 3) portupgrade (or even port dependency checking) doing an 'ldd' on each dependency and either complaining or rebuilding any where the dependency predates a library bump. (Doing this properly probably means building the port then discovering that it now needs multiple .so versions and having to rebuild it after cleaning up the offending dependency). Note that 2 and 3 don't pick up .so's that are dlopen()d by the code and 3 only works for ports. This is off the top of my head and further thought may suggest reasons why the above aren't practical. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050318190828.GC30813>