#503 closed bug (Fixed)
Changes to setup.py to workaround broken boost packages
Reported by: | pscott@foresightlinux.org | Owned by: | markybob |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Packaging | Version: | 1.0.0 |
Keywords: | Cc: |
Description
To package deluge=1.0.0
for Foresight I needed to change setup.py
to workaround a broken boost package. The changes made could help other packagers build Deluge.
Firstly /usr/lib/libboost_filesystem.so
only exists when building for x86, for x86_64 it is in /usr/lib64
, I suggest changing the logic to use LIBDIR
rather than /usr/lib
explicitly.
Secondly all the boost libraries *except* boost_thread
are available as both -mt and non -mt. To workaround that I changed it explicitly in _libraries
. However combined with the first problem however this failed unexpectedly building for both arches - it tried to use boost_thread-mt-mt
. So I added a further check before appending -mt.
Attachments (2)
Change History (9)
by , 17 years ago
Attachment: | modify-boost-detection.patch added |
---|
comment:1 by , 17 years ago
Forgot to add information about automatic detection. Foresight /etc/issue
is empty but /etc/distro-release
contains Foresight Linux
.
Further, even with those two changes the package still needs to explicitly change _libraries
to use boost_thread-mt
. However with those changes there is no unexpected outcome of doing so, ie boost_thread-mt-mt
.
Strictly speaking that's because of the LIBDIR change but I think it still makes sense to check if it ends in -mt 'just in case'.
comment:2 by , 17 years ago
I agree with the reporter, however I disagree with his suggestion that this is due to a "broken package". It's just bad detection logic on the part of deluge. The part about libdir is a no-brainer, but the second part is equally wrong on Deluge's side. It should not assume that libboost_filesystem.so would always just be a symlink to libboost_filesystem-mt.so , which appears to be the current underlying assumption. On Mandriva, like Foresight, the boost packages contain both single-threaded and multithreaded versions of the library; so if you just use libboost_filesystem.so , you are getting a single-threaded boost, not the multithreaded one.
I know this logic has been changed zillions of times, but the current setup just ain't right.
For now in Mandriva I've changed it to a positive test for libboost_filesystem-mt.so , using LIBDIR:
--- deluge-1.0.0/setup.py 2008-09-21 12:22:24.000000000 -0700 +++ deluge-1.0.0/setup.py.new 2008-09-24 08:41:13.000000000 -0700 @@ -145,9 +145,8 @@
]
# Modify the libs if necessary for systems with only -mt boost libs
- if not os.path.exists(
- os.path.join(sysconfig.PREFIX, "lib", "libboost_filesystem.so")):
- # It's likely that this system doesn't have symlinks setup
+ if os.path.exists(os.path.join(sysconfig.get_config_vars()LIBDIR, \ + 'libboost_filesystem-mt.so')):
# So add '-mt' to the libraries for lib in _libraries:
if lib[:6] == "boost_":
so if it *does* find a libboost_filesystem-mt.so , it adds -mt to all the lib names.
The lack of libboost_thread-mt.so would torpedo this for Foresight, I guess, but at least it'd be closer.
comment:4 by , 17 years ago
I should have been clearer, Foresight has a libboost_thread-mt.so
but no libboost_thread.so
. Looking for libboost_filesystem-mt.so
and appending -mt if it exists ought to work on Foresight.
Looking at it again the second part of my patch is redundant, left over from an earlier attempt to build for both architectures.
comment:5 by , 17 years ago
Milestone: | → 1.0.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
I have committed [3867] to hopefully fix this. The logic will not check for each boost lib's multithreaded version (-mt) first and if not available it will use the regular non mt lib. It does this for each boost lib.
Let me know if there are still issues.
Patch to add libdir and check for libraries ending -mt