I don't have any problem with this conceptually. The sys.platform.startswith() would be better as a function perhaps (is_openbsd() or maybe just is_bsd()). Is this also true for freebsd for instance? And a more flexible way of handling the multi-part version numbers would be welcome, perhaps as a separate patch.
If you can submit this as a mercurial patch, ideally with a testcase (SCons uses TDD), we should be able to work it in. (As I look at it, it's clear that Tool/__init__.py is not the right place for this logic anyway. But that's a separate issue. Better to capture the correct behavior now and refactor it later when redoing Tools.) On Thu, Sep 5, 2013 at 11:40 AM, Stefan Sperling <s...@openbsd.org> wrote: > Hi, > > as discussed on IRC today, and on the OpenBSD ports list at > http://marc.info/?l=openbsd-ports&m=137831857808220&w=2, > soname support in scons 2.3.0 is interfering a little bit with > OpenBSD's way of handling shared libraries. > > The patch below (against the rel_2.3.0 branch) does the minimum > necessary to prevent that. Is it acceptable? > > I was thinking that instead of making behaviour conditional on the host > platform, a generic switch could be used to toggle generation of a soname, > and the same for creation of symlinks. Though perhaps that would be > overkill or conflict with scons goals, I don't know. > Anyway, the below works for me. > > One additional issue is that OpenBSD uses an x.y shared library version > numbering scheme, which scons does not support. This can be worked around > by renaming shared libraries after the build. > I'm not sure how much needs to be done to fix this. There is a comment in > the VersionShLibLinkNames() function that some adjustments would need to > be made. Are there plans to support such versioning schemes in a future > release of scons? > > Thanks. > > Suggested log message: > > [[[ > OpenBSD-specific fixes for shared library handling. > > Don't put a SONAME into shared lbraries, and don't create symlinks > between .so files. OpenBSD uses a different approach to shared library > handling, and in particular setting a SONAME that doesn't match the .so > file name can confuse automated checks performed by its ports framework. > See http://marc.info/?l=openbsd-ports&m=137831857808220&w=2 > ]]] > > diff -r 05db74dca43c src/engine/SCons/Tool/__init__.py > --- a/src/engine/SCons/Tool/__init__.py Sun Mar 03 19:34:10 2013 -0500 > +++ b/src/engine/SCons/Tool/__init__.py Thu Sep 05 16:26:07 2013 +0200 > @@ -257,6 +257,10 @@ > print "VersionShLibLinkNames: linkname = ",linkname > linknames.append(linkname) > elif platform == 'posix': > + if sys.platform.startswith('openbsd'): > + # OpenBSD uses x.y shared library versioning numbering > convention > + # and doesn't use symlinks to backwards-compatible libraries > + return [] > # For libfoo.so.x.y.z, linknames libfoo.so libfoo.so.x.y > libfoo.so.x > suffix_re = re.escape(shlib_suffix + '.' + version) > # First linkname has no version number > @@ -302,13 +306,17 @@ > if version: > # set the shared library link flags > if platform == 'posix': > - suffix_re = re.escape(shlib_suffix + '.' + version) > - (major, age, revision) = version.split(".") > - # soname will have only the major version number in it > - soname = re.sub(suffix_re, shlib_suffix, libname) + '.' + > major > - shlink_flags += [ '-Wl,-Bsymbolic', '-Wl,-soname=%s' % soname > ] > - if Verbose: > - print " soname ",soname,", shlink_flags ",shlink_flags > + shlink_flags += [ '-Wl,-Bsymbolic' ] > + if sys.platform.startswith('openbsd'): > + pass # OpenBSD doesn't usually use SONAME for libraries > + else: > + suffix_re = re.escape(shlib_suffix + '.' + version) > + (major, age, revision) = version.split(".") > + # soname will have only the major version number in it > + soname = re.sub(suffix_re, shlib_suffix, libname) + '.' + > major > + shlink_flags += [ '-Wl,-soname=%s' % soname ] > + if Verbose: > + print " soname ",soname,", shlink_flags ",shlink_flags > elif platform == 'cygwin': > shlink_flags += [ '-Wl,-Bsymbolic', > '-Wl,--out-implib,${TARGET.base}.a' ] > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev > -- Gary
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
