Tiny Core Linux
Tiny Core Extensions => TCE News => TCE 3.x => Topic started by: Jason W on June 04, 2010, 09:23:41 PM
-
Thanks to robc for:
Title: boost-dev.tcz
Description: Peer-reviewed portable C++ source libraries Development Files (TESTING)
Version: 1.43.0
Author: Various (http://www.boost.org/users/people.html)
Original-site: http://www.boost.org/
Copying-policy: Boost Software License v1.0 (http://www.boost.org/LICENSE_1_0.txt)
Size: 10.7M
Extension_by: robc
Comments:
----------------------------------------------
Please see the man page for additional
information.
Also see http://www.boost.org/
for more information.
----------------------------------------------
Change-log: 2009/08/05 Original
2009/10/28 Updated to v1.40.0
2010/01/22 Updated to v1.41.0
2010/06/04 Updated to v1.43.0
Current: 2010/06/04 Updated to v1.43.0
Title: boost.tcz
Description: Peer-reviewed portable C++ source libraries (TESTING)
Version: 1.43.0
Author: Various (http://www.boost.org/users/people.html)
Original-site: http://www.boost.org/
Copying-policy: Boost Software License v1.0 (http://www.boost.org/LICENSE_1_0.txt)
Size: 2.7M
Extension_by: robc
Comments:
----------------------------------------------
Please see the man page for additional
information.
Also see http://www.boost.org/
for more information.
----------------------------------------------
Change-log: 2009/08/05 Original
2009/10/28 Updated to v1.40.0
2010/01/22 Updated to v1.41.0
2010/06/04 Updated to v1.43.0
Current: 2010/06/04 Updated to v1.43.0
-
Please enable static libs (preferably without the dynamic ones) on the next update.
Boost declares an ABI break on every update, forcing all depending extensions to a rebuild. Unwanted behavior, IMO.
Linking boost and only it statically removes this.
-
no need to static link, i suggest putting version numbers to boost and not deleting old ones except their dev packages (*.so symlinks must be deleted from lib extensions)
for example
boost-1.41 (without lib*.so)
boost-1.42 (without lib*.so)
boost-1.43 (with lib*.so)
boost-dev --> which is actually boost-1.43-dev
thus all new extensions will be linked to latest boost while old ones won't be broken with each boost update
similar approach can be applied to other such extensions like icu
extension maintainers can easily handle this case
-
I think it would be good to enable and allow static linking in this case. If I was building against boost, I would static link to avoid the potential version pitfalls.
But either way we should give a version number to the boost package. If the -dev package is not version numbered, it would be good to state in the info file that it one would need to update it upon each update of the main boost extension.
-
Jason, do you have the 1.41 version still somewhere?
-
It is still in the gmail account. I can rename it to boost-1.41, remove the .so symlinks, and upload it if need be.
-
also remove python2.6 directory because these files do not belong to boost
see python.tcz.list
i didn't check boost build script but this usually happens when using
touch /tmp/mark
sudo make install (this also may execute post install commands and eventually some files are modified)
find /usr -newer /tmp/mark ...
-
boost-1.41.tcz has been uploaded to 2.x and 3.x repo.
Here is a list of extensions that depend on the 1.41 version of boost, I will update the dep files momentarily.:
2.x
gnash.tcz
gnote.tcz
libtorrent-rasterbar.tcz
mkvtoolnix.tcz
3.x
akonadi.tcz
gnash.tcz
gnote.tcz
libtorrent-rasterbar.tcz
mkvtoolnix.tcz
-
Thanks, Jason.
-
boost has been updated to 1.44 and submitted.
this update is in three extensions:
boost.tcz - shared libs
boost-static.tcz - static libs
boost-dev.tcz - development files
Edit: The email failed. I think the attachment is too big, I will split it up and send as two later today.
-
i think there is no choice but version numbering boost because every update anything that depends on boost is broken, however i have two suggestions
1-) version number every boost (and create a virtual boost.tcz that points to latest boost maybe)
2-) keep only one boost for the life time of a major tc release (2, 3, 4)
-
I fully agree with Arslan on this. Like Python, openssl, kernel, XOrg, and similar. I think that makes much more efficient and productive use of the time of our small but active contributors not to update things like this in mid stream that require a coordinated rebuild and update effort affecting other extensions.
-
This is the first version of boost that was built on 3.x. The others were built on 2.x. I also included both shared and static libs since they both should be available anyway.
Having a more planned update for boost is fine.