Changes to setup.py to workaround broken boost packages

[pscott@…]

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.

[pscott@…]

Patch to add libdir and check for libraries ending -mt

[pscott@…]

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'.

[anonymous]

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.

[anonymous]

Bah, I forgot Trac eats patches for breakfast. I'll attach it.

[anonymous]

Mandriva patch

[pscott@…]

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.

[andar]

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.

[pscott@…]

[3867] built fine on Foresight.

[anonymous]

Milestone 1.0.1 deleted

[balko]

Форум о мобильных телефонах