Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
boost libs
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Superfox_il_Volpone
n00b
n00b


Joined: 14 Aug 2012
Posts: 23

PostPosted: Sat Nov 10, 2012 9:27 am    Post subject: boost libs Reply with quote

Hi,
in the last update of the environment I lost boost 1.48, obtained through the single shot =dev-libs/boost-1.48. I was keeping that version for development purposes. I cannot find it anymore in the emerge repository. Now, the update of environment asks to pass to boost 1-52 and to remove eselect-boost:
Code:

[ebuild     U ~] dev-libs/boost-1.52.0-r1 [1.49.0-r1] USE="python threads%* -debug -doc -icu -mpi -static-libs -tools (-eselect%*) (-test%)" 0 kB
[uninstall     ] app-admin/eselect-boost-0.4
[blocks b      ] app-admin/eselect-boost ("app-admin/eselect-boost" is blocking dev-libs/boost-1.52.0-r1)

I guess gentoo developers removed the feature to keep more boost versions? What should I have done to avoid the unmerging of that specific version? To maintain a specific library, do I have to manually install it in a home prefix?

Regards
- s.fox
Back to top
View user's profile Send private message
phalaxy
Tux's lil' helper
Tux's lil' helper


Joined: 12 Aug 2008
Posts: 115

PostPosted: Sat Nov 10, 2012 10:02 am    Post subject: Reply with quote

hi,

Quote:
To maintain a specific library, do I have to manually install it in a home prefix?


better it is ... not comfortable, but possible

by the way my own opinion : damm boost devs - they did break their own api again WITHOUT changing the major version number from 1.x.x to 2.x.x
_________________
Acer Aspire 7745G Notebook 1.15 Bios
Intel Core-i7 720QM
8 GB RAM
ATI Mobility Radeon 5850 1GB VRAM
Gentoo Linux ~amd64 non-multilib

SWAP ??? Deprecated now ... :-)
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 5437

PostPosted: Sat Nov 10, 2012 2:25 pm    Post subject: Reply with quote

Well, in this case (at least according to a post on gentoo-dev), it's glibc that started to use a value in 2.16, that somewhere deep down boost also used.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8852

PostPosted: Sat Nov 10, 2012 4:21 pm    Post subject: Re: boost libs Reply with quote

Superfox_il_Volpone wrote:
Hi,
in the last update of the environment I lost boost 1.48, obtained through the single shot =dev-libs/boost-1.48. I was keeping that version for development purposes. I cannot find it anymore in the emerge repository. Now, the update of environment asks to pass to boost 1-52 and to remove eselect-boost:
Code:

[ebuild     U ~] dev-libs/boost-1.52.0-r1 [1.49.0-r1] USE="python threads%* -debug -doc -icu -mpi -static-libs -tools (-eselect%*) (-test%)" 0 kB
[uninstall     ] app-admin/eselect-boost-0.4
[blocks b      ] app-admin/eselect-boost ("app-admin/eselect-boost" is blocking dev-libs/boost-1.52.0-r1)

I guess gentoo developers removed the feature to keep more boost versions? What should I have done to avoid the unmerging of that specific version? To maintain a specific library, do I have to manually install it in a home prefix?
Could you explain why you want to maintain an obsolete version? Staying on a legacy version indefinitely is asking for trouble. Eventually, something will change in an incompatible way, and then the maintainers must either remove the obsolete version or spend effort modifying it to adjust for the incompatible change. As VoidMage notes, new versions of glibc interfere with building old versions of Boost. New versions of Boost have already been adjusted to work properly.

phalaxy wrote:
by the way my own opinion : damm boost devs - they did break their own api again WITHOUT changing the major version number from 1.x.x to 2.x.x
Changing the major version would not help you. The only solutions are either to support slotted installs or to release transition versions which support both the old and new API. Gentoo tried using slotted installs and it caused significant work for questionable gain.
Back to top
View user's profile Send private message
Superfox_il_Volpone
n00b
n00b


Joined: 14 Aug 2012
Posts: 23

PostPosted: Sat Nov 10, 2012 9:31 pm    Post subject: Re: boost libs Reply with quote

Hu wrote:
Could you explain why you want to maintain an obsolete version?

Superfox_il_Volpone wrote:
I was keeping that version for development purposes.


what the hell guys, it gets frustrating when the system does not behave as you would have figured out. If someone wants to install a specific program, that is slotted, he will reasonable expect that the system, for no reason would ever never whatever change, nor delete it. It could be buddy, dangerous, a symptom of masochism, the program may even create a large black hole sucking all the universe inside. It is not your business, leave it there as it is.

regards
s.fox
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8852

PostPosted: Sat Nov 10, 2012 10:06 pm    Post subject: Reply with quote

Though the developers removed it from the tree, the package manager left it on the system until you removed it. I saw your initial statement that you were keeping it for "development purposes," but I do not understand why you think that keeping an arbitrary obsolete version, which cannot be rebuilt using newer tools, is a good idea. If you are developing code that uses Boost, you should upgrade to the new version.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2410
Location: The Peanut Gallery

PostPosted: Sat Nov 10, 2012 10:24 pm    Post subject: Reply with quote

sfox,

I agree with you that it should not have suddenly disappeared like that. But it has. Unfortunately I can only see 1.46 on the official tinderbox and 1.35(!) on Patrick's binhost which is usually more up to date.

To avoid this kind of thing, I use FEATURES=buildpkg: I know it's no help now, but if you had it setup, you would have had a built binpkg for your system. I hope you can see how that might be useful in future.

I have boost-1.48.0-r2 and boost-1.49.0-r1 built for stable amd64 with USE: doc eselect icu mpi tools -debug -python -static-libs -test. But you need python, and don't have eg icu set. That's why buildpkg is so important.

What you can do now, is get the old ebuild out of the attic (bookmark that second link), and put it in a local overlay then just emerge it again, after masking the newer version. (You'll need to cd to dev-libs/boost and run repoman manifest.) You will also need things out of the files/ subdirectory as well: reading the ebuild and running repoman/ emerge will soon tell you what you're missing.

Obviously, if I were you, I'd set up buildpkg first ;-)

Good luck,
steveL.
Back to top
View user's profile Send private message
phalaxy
Tux's lil' helper
Tux's lil' helper


Joined: 12 Aug 2008
Posts: 115

PostPosted: Sun Nov 11, 2012 10:10 am    Post subject: Reply with quote

... or merging code from boost to your own project and never worry about boost bogus at all again, but you have maintain the boost code you use additionally to your own code. by this way you reduce external project depencies. your decision ...
_________________
Acer Aspire 7745G Notebook 1.15 Bios
Intel Core-i7 720QM
8 GB RAM
ATI Mobility Radeon 5850 1GB VRAM
Gentoo Linux ~amd64 non-multilib

SWAP ??? Deprecated now ... :-)
Back to top
View user's profile Send private message
geki
Advocate
Advocate


Joined: 13 May 2004
Posts: 2114
Location: Germania

PostPosted: Sun Nov 11, 2012 4:09 pm    Post subject: Reply with quote

another possibility would be my overlay. I maintain boost slotted. I know it too well to keep old crap around. :o

check my sig: split-boost
_________________
boost|trans-follow xcb|instruction set analyzer
___
the self obscures the truth. I am no one, and so my words alone come from the truth of this world. amen.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8852

PostPosted: Sun Nov 11, 2012 4:22 pm    Post subject: Reply with quote

phalaxy wrote:
... or merging code from boost to your own project and never worry about boost bogus at all again, but you have maintain the boost code you use additionally to your own code. by this way you reduce external project depencies. your decision ...
This works, but is a great way to make package maintainers hate you. Bundled libraries are evil.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2410
Location: The Peanut Gallery

PostPosted: Sun Nov 11, 2012 10:38 pm    Post subject: Reply with quote

Hu wrote:
phalaxy wrote:
... or merging code from boost to your own project and never worry about boost bogus at all again, but you have maintain the boost code you use additionally to your own code. by this way you reduce external project depencies. your decision ...
This works, but is a great way to make package maintainers hate you. Bundled libraries are evil.

I'm fairly sure I read on the dev ML during recent discussion about this change, that boost recommends you bundle its code. It was mentioned as one of the contributory factors, along with "no other distro keeps multiple versions."

I'm not really sure what I make of that: if there is an issue with two projects using different versions of boost, whereby a slotted library still might fail due to conflicting symbols, doesn't that apply equally if they're both bundling different versions? Or are the developers supposed to use it internally only: how do they ensure symbols still don't clash? Sounds like a nightmare to me.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8852

PostPosted: Sun Nov 11, 2012 10:59 pm    Post subject: Reply with quote

Yes, some upstream projects recommend that you bundle them. This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases.

For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2410
Location: The Peanut Gallery

PostPosted: Mon Nov 19, 2012 9:34 am    Post subject: Reply with quote

Hu wrote:
Yes, some upstream projects recommend that you bundle them. This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases.

ABI compatibility (which requires API compatibility) is the crux.
Quote:
For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code.

And what about Boost itself recommending bundling of its code?
Back to top
View user's profile Send private message
MustrumR
n00b
n00b


Joined: 15 Nov 2011
Posts: 51
Location: Right here

PostPosted: Mon Nov 19, 2012 12:12 pm    Post subject: Reply with quote

Bundling third-party code is wrong. It's like going back to a.out times, just a bit worse.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8852

PostPosted: Tue Nov 20, 2012 2:22 am    Post subject: Reply with quote

steveL wrote:
Hu wrote:
Yes, some upstream projects recommend that you bundle them. This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases.

ABI compatibility (which requires API compatibility) is the crux.
As users, we care about whether the project retains ABI compatibility. For developers, they care mostly about API compatibility. For a developer, if the API remains compatible, asking the user to rebuild with the latest headers is easy, since it does not require the developer to modify the code to handle the different versions of the underlying library.
steveL wrote:
Quote:
For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code.

And what about Boost itself recommending bundling of its code?
Could you rephrase the question? I stand by my statement that I dislike bundling, but that in some cases you can get away with it. That statement is independent of whether the project being bundled advocates bundling, because the statement is predicated on the probability that the bundling will cause more problems than it solves. Although the library project can take steps to make it easier for the bundler to avoid problems, the only way to be completely safe is to ensure that all programs using the library code load exactly the same copy of the supporting library. This is easiest when bundling does not occur.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2410
Location: The Peanut Gallery

PostPosted: Thu Nov 22, 2012 7:26 am    Post subject: Reply with quote

Hu wrote:
steveL wrote:
ABI compatibility (which requires API compatibility) is the crux.
As users, we care about whether the project retains ABI compatibility. For developers, they care mostly about API compatibility. For a developer, if the API remains compatible, asking the user to rebuild with the latest headers is easy, since it does not require the developer to modify the code to handle the different versions of the underlying library.

I know full well what developers are like (and also the difference with a developer who cares about their users, who will care about ABI.)
The point I was making was in the context of your remark that "This attitude seems to be more common in the projects where they dislike keeping API compatibility across releases." I was saying that actually it's more common where they dislike monitoring ABI compatibility, which yes is because of changes in API, but not necessary loss of API compatibility.

For instance, changing a function to take a long parameter instead of an int, maintains API compatibility in that existing code that calls it with an int argument, will still work with that "easy rebuild" against new headers. It totally screws ABI compatibility though, and requires a change in symbol and/or major version, or a different function.

This is why you get projects like udev or systemd going through frequent major version changes, apparently emulating the kernel, badly. They forget that the kernel only has a flexible attitude to internal interfaces: externally exported interfaces are pretty much set in stone. An example would be epoll_create and epoll_create1 (see man epoll_create.)
Quote:
steveL wrote:
Quote:
For the header-only Boost libraries, bundling them is probably safe, but I still think it is a bad idea. For the libraries which also build a shared object, you are correct that there are substantial risks if the users of the libraries do not take special steps to hide the Boost symbols from other code.

And what about Boost itself recommending bundling of its code?
Could you rephrase the question? I stand by my statement that I dislike bundling, but that in some cases you can get away with it. That statement is independent of whether the project being bundled advocates bundling, because the statement is predicated on the probability that the bundling will cause more problems than it solves. Although the library project can take steps to make it easier for the bundler to avoid problems, the only way to be completely safe is to ensure that all programs using the library code load exactly the same copy of the supporting library. This is easiest when bundling does not occur.

Oh I totally agree with you about bundling libraries. My point was that boost is still recommending developers bundle their code, and especially in the case of headers that could cause an issue, if your goal is to ensure all packages use the same centrally managed version. A properly setup build-system should cover that, but upstream developers might not think it a concern, given that boost has recommended bundling, which leaves more education needing to be done by Gentoo devs, usually by having to provide patches which also means more work.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum