Release Showstoppers Take 2

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Release Showstoppers Take 2

kintel
Administrator
Hi all,

I believe all showstoppers reported last time are now dealt with, so I'm making a last call: If anyone stumbles across any release showstoppers, please report back as soon as possible.
I'm planning to have a release candidate out within a week, and a final release before the end of the year.

A few notes:
1) Once we get this one out, it should be possible to release more rapidly from now on.
2) I'll be at the CCC congress in Berlin December 26-30, so there are possibilities for a meetup/hackup/release party there :)

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

Torsten Wagner
Hi,

I am not pretty sure if this is a openscad build or a Arch Linux
problem. Recently, I received an report that the package openscad-git
failed due to a missing libboost_thread.
   libboost_thread.so.1.48.0
whereas openscad (opencgal) is looking for
   libboost_thread.so.1.47.0

Arch Linux has already a symlink "libboost_thread" which should point to
the latest version and which I would believe is the most sane way to use.

I only looked quickly into it and couldn't figure out where, why and how
to make sure it will work with libboost_thread.so.1.48.0
Creating a symlink libboost_thread.so.1.47.0 ->
libboost_thread.so.1.48.0 seems to work as a hack.

Is it possible to update the requirements for compilation?

Torsten








On 12/13/2011 10:02 AM, Marius Kintel wrote:

> Hi all,
>
> I believe all showstoppers reported last time are now dealt with, so I'm making a last call: If anyone stumbles across any release showstoppers, please report back as soon as possible.
> I'm planning to have a release candidate out within a week, and a final release before the end of the year.
>
> A few notes:
> 1) Once we get this one out, it should be possible to release more rapidly from now on.
> 2) I'll be at the CCC congress in Berlin December 26-30, so there are possibilities for a meetup/hackup/release party there :)
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

kintel
Administrator
On Dec 16, 2011, at 07:29 AM, Torsten Wagner wrote:
>
> I am not pretty sure if this is a openscad build or a Arch Linux problem. Recently, I received an report that the package openscad-git failed due to a missing libboost_thread.
>  libboost_thread.so.1.48.0
> whereas openscad (opencgal) is looking for
>  libboost_thread.so.1.47.0
>
This looks like a packaging issue on arch linux.
It sounds like someone has been building from source on a machine where a different version of boost is installed.
If you always install from source you should be home free. I'm not sure how the arch linux packaging works though.

I guess it would be cool if the arch linux package maintainer is subscribed here and we could solve such issues as they arise.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

donbright
In reply to this post by Torsten Wagner
do you have a copy of the report? what is "openscad (opencgal)"? i am
not familiar with arch linux

Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

Torsten Wagner
In reply to this post by kintel
Well,
for openscad-git I am the maintainer. I am not an Arch-linux guru.
There are basically two systems. The standard package system with
packages updated as soon as the maintainer find out about a new official
release.

However, Arch-linux allows to write package build descriptions called
PKGBUILDS as user contribution. Within this PKGBUILD it will be
described how to fetch the source code, e.g. from git and how to run
trough an autonomous build process in a chroot. In the easiest case the
PKGBUILD will do exactly what you would do on the terminal ... e.g.,
cmake, make, make install.  Finally, the content of the chroot will be
packed into a single package file for installation.

This allows Arch-Linux users to follow very close actual development of
a software project. People who use these packages are aware of the pro
and con, however, at least the installation should work out-of-the-box.

The described error appeared for openscad-git. My guess would be that
the reporter compiled openscad from git (using the openscad-git package)
and later updated to libboost_thread.so.1.48.0.

I would like to know if at some point the linker needs to be told to use
the symlink libboost_thread which would be valid at all time.

Totti



On 12/16/2011 09:51 PM, Marius Kintel wrote:

> On Dec 16, 2011, at 07:29 AM, Torsten Wagner wrote:
>>
>> I am not pretty sure if this is a openscad build or a Arch Linux problem. Recently, I received an report that the package openscad-git failed due to a missing libboost_thread.
>>   libboost_thread.so.1.48.0
>> whereas openscad (opencgal) is looking for
>>   libboost_thread.so.1.47.0
>>
> This looks like a packaging issue on arch linux.
> It sounds like someone has been building from source on a machine where a different version of boost is installed.
> If you always install from source you should be home free. I'm not sure how the arch linux packaging works though.
>
> I guess it would be cool if the arch linux package maintainer is subscribed here and we could solve such issues as they arise.
>
>   -Marius
>


Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

donbright
if a program was compiled and link against boost 1.47.0 originally,
and it gets forced-to-run against boost 1.48.0, then there will
probably be subtle bugs and/or crashes.

see also

http://stackoverflow.com/questions/5757566/c-dynamic-library-compiling-linking
http://boost.2283326.n4.nabble.com/ABI-and-API-compatibility-td2643120.html
http://stackoverflow.com/questions/2907882/using-concurrently-2-versions-of-boost

openscad uses libboost_thread and libboost_program_options.

DB

Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

Torsten Wagner
I will check upstream on Arch Linux how to deal with this.
In the package build file I can set dependencies. However, in general
if an lib receives an update, there should be a mechanism how to deal
with the programs compiled for the old libs. I would assume, they
simply keep the old lib too, which might did not happen in that case
(maybe because I misconfigured the package dependencies). It would be
either using an old lib, or  tracking all libs and make sure that to
upgrade the package whenever a lib changed. There should be a more
smart way of doing it.


Torsten


On 19 December 2011 13:50, Don Bright <[hidden email]> wrote:

> if a program was compiled and link against boost 1.47.0 originally,
> and it gets forced-to-run against boost 1.48.0, then there will
> probably be subtle bugs and/or crashes.
>
> see also
>
> http://stackoverflow.com/questions/5757566/c-dynamic-library-compiling-linking
> http://boost.2283326.n4.nabble.com/ABI-and-API-compatibility-td2643120.html
> http://stackoverflow.com/questions/2907882/using-concurrently-2-versions-of-boost
>
> openscad uses libboost_thread and libboost_program_options.
>
> DB
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

kintel
Administrator
On Dec 19, 2011, at 15:12 PM, Torsten Wagner wrote:

> I will check upstream on Arch Linux how to deal with this.

Please do.
I guess this is a problem due to boost not offering binary compatibility between versions, and thus encode the version number into the filename of the libraries. This means that all previous versions of boost need to be installed on a system to avoid having to rebuild all dependencies once you upgrade boost. This must be a common issue and there's probably a standard way of handling it.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

Torsten Wagner
Hi,
o.k. I did a bit IRC chatting.
It seems Arch Linux does not provide any mechanismen to check for
dependencies downstream with AUR-packages.
AUR are user-submitted ARCH-package files. E.g., openscad-git is one of
them.
If a lib change, the Arch maintainer makes sure, that all officla
packages depending on that lib will be recompiled and flag as update.
Arch does not store multiple versions of a lib.
However, they do (and can't do) this for all packages on the AUR
website. It would break the idea of a user-based package repro.

The idea is, if users want bleeding edge software like openscad from the
recent git, they have to live with the fact that they might have to
upgrade the installation whenever a lib changes. Updating is a simple
oneliner no-brainer. Building and installation will be done automatically.

Thus if there is a prob, people are advice to first try updating the
package to make sure it is compiled against the recent lib versions.

Honestly speaking I find this a bit of an poor decision and I would like
to see mechanisms which at least allow the maintainers of AUR packages
to be informed of any changes in the package dependencies.

Long story short... it seems not to be an issue within openscad.
Thus, green light for a release from the Arch Linux people :)

Totti



On 12/20/2011 12:14 AM, Marius Kintel wrote:

> On Dec 19, 2011, at 15:12 PM, Torsten Wagner wrote:
>
>> I will check upstream on Arch Linux how to deal with this.
>
> Please do.
> I guess this is a problem due to boost not offering binary compatibility between versions, and thus encode the version number into the filename of the libraries. This means that all previous versions of boost need to be installed on a system to avoid having to rebuild all dependencies once you upgrade boost. This must be a common issue and there's probably a standard way of handling it.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

donbright
One solution is to statically link the boost .a libraries statically
into openscad. The problem is that CGAL also depends on boost. So you
have to statically link it too. How?

1. Get a clean clone of openscad from git.
2. add something like this to the end of boost.pri

 CONFIG(linux-link-static) {
    LIBS -= -lboost_thread-mt -lboost_program_options-mt
    LIBS -= -lboost_thread -lboost_program_options
    DEFINES += BOOST_STATIC
    DEFINES += BOOST_THREAD_USE_LIB
    DEFINES += Boost_USE_STATIC_LIBS
    LIBS += /usr/lib/libboost_program_options.a
    LIBS += /usr/lib/libboost_thread.a
  }

3. add something like this to the end of cgal.pri

  CONFIG(linux-link-static) {
    LIBS -= -lCGAL
    LIBS += /usr/lib/libCGAL.a
  }

4. run qmake with special flags

 qmake-qt4 CONFIG+=linux-link-static
 make

5. double check to make sure it worked

 ldd ./openscad

There will be a bunch of dynamic links, but CGAL and boost should not
be among them.

-DB


> Honestly speaking I find this a bit of an poor decision and I would like
> to see mechanisms which at least allow the maintainers of AUR packages
> to be informed of any changes in the package dependencies.
>

Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

donbright
of course some distributions frown on anything packaged with
statically linked libraries...

i.e. see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137984

but i am not familiar with Arch philosophy on this.

-DB

Reply | Threaded
Open this post in threaded view
|

Re: Release Showstoppers Take 2

Triffid Hunter
In reply to this post by Torsten Wagner
On Tue, Dec 20, 2011 at 12:31 PM, Torsten Wagner
<[hidden email]> wrote:
> Honestly speaking I find this a bit of an poor decision and I would like
> to see mechanisms which at least allow the maintainers of AUR packages
> to be informed of any changes in the package dependencies.

gentoo is fantastic in this regard, the package manager does its best
to keep track of this stuff, and if it fails we have tools to hunt
down affected files and select packages to recompile. these features
work regardless of whether the packages come from an official
repository or 3rd party repositories or even local custom packages.

If anyone wants openscad and opencsg gentoo ebuilds, just ask, mine
seem to work :)