Since sublevel releases are not ABI compatible we need to adjust
the soname to include the sublevel version.
This makes it possible to install ABI incompatible versions of the
library side by side so clean upgrades are possible.
---
Makefile.in| 10 +-
Ma
On Tue, Apr 20, 2010 at 4:49 PM, Natanael Copa wrote:
> Since sublevel releases are not ABI compatible we need to adjust
> the soname to include the sublevel version.
...
> diff --git a/libpthread/nptl/Makefile.in b/libpthread/nptl/Makefile.in
> index d9f2d23..1e9f98c 100644
> --- a/libpthread/
On Tue, 20 Apr 2010, Natanael Copa wrote:
> Since sublevel releases are not ABI compatible we need to adjust
> the soname to include the sublevel version.
I see two reasons that this would be pointless.
First, you'd need more than a more precise statement of the uClibc source
version, because wit
Michael Deutschmann wrote:
On Tue, 20 Apr 2010, Natanael Copa wrote:
Since sublevel releases are not ABI compatible we need to adjust
the soname to include the sublevel version.
I see two reasons that this would be pointless.
First, you'd need more than a more precise statement of the uClibc
On Thu, Apr 22, 2010 at 8:54 AM, Michael Deutschmann
wrote:
> On Tue, 20 Apr 2010, Natanael Copa wrote:
>> Since sublevel releases are not ABI compatible we need to adjust
>> the soname to include the sublevel version.
>
> I see two reasons that this would be pointless.
>
> First, you'd need more
On Thu, 22 Apr 2010, Natanael Copa wrote:
> Do you have any better suggestions how to upgrade a running system?
First, build the new uClibc, but don't install it yet.
Build a customized ld-uclibc.so.0, from the previous uClibc source, that
looks in a different place for shared libraries and ignor
Michael Deutschmann wrote:
On Thu, 22 Apr 2010, Natanael Copa wrote:
Do you have any better suggestions how to upgrade a running system?
First, build the new uClibc, but don't install it yet.
Build a customized ld-uclibc.so.0, from the previous uClibc source, that
looks in a different place f
On Thu, Apr 22, 2010 at 12:10 PM, Michael Deutschmann
wrote:
> On Thu, 22 Apr 2010, Natanael Copa wrote:
>> Do you have any better suggestions how to upgrade a running system?
>
> First, build the new uClibc, but don't install it yet.
>
> Build a customized ld-uclibc.so.0, from the previous uClibc
On 04/20/2010 07:49 AM, Natanael Copa wrote:
> Since sublevel releases are not ABI compatible we need to adjust
> the soname to include the sublevel version.
>
> This makes it possible to install ABI incompatible versions of the
> library side by side so clean upgrades are possible.
> ---
> Makef
On Thu, 22 Apr 2010, Timo wrote:
> This really is configuration management issue, and doable inside a single
> distribution.
I don't understand what "configuration management" means. Perhaps this
is why I don't quite get you and Natanael...
Basically, my point is that in general, changing the so
Michael Deutschmann wrote:
On Thu, 22 Apr 2010, Timo wrote:
This really is configuration management issue, and doable inside a single
distribution.
I don't understand what "configuration management" means. Perhaps this
is why I don't quite get you and Natanael...
It means the system used to
Austin Foxley wrote:
On 04/20/2010 07:49 AM, Natanael Copa wrote:
Since sublevel releases are not ABI compatible we need to adjust
the soname to include the sublevel version.
This makes it possible to install ABI incompatible versions of the
library side by side so clean upgrades are possible.
On 04/23/2010 07:18 AM, Timo Teräs wrote:
> Austin Foxley wrote:
>> On 04/20/2010 07:49 AM, Natanael Copa wrote:
>>> Since sublevel releases are not ABI compatible we need to adjust
>>> the soname to include the sublevel version.
>>>
>>> This makes it possible to install ABI incompatible versions o
Austin Foxley wrote:
On 04/23/2010 07:18 AM, Timo Teräs wrote:
Austin Foxley wrote:
On 04/20/2010 07:49 AM, Natanael Copa wrote:
Since sublevel releases are not ABI compatible we need to adjust
the soname to include the sublevel version.
This makes it possible to install ABI incompatible vers
On 4/23/10, Austin Foxley wrote:
> On 04/23/2010 07:18 AM, Timo Teräs wrote:
> > Austin Foxley wrote:
> >> On 04/20/2010 07:49 AM, Natanael Copa wrote:
> >>> Since sublevel releases are not ABI compatible we need to adjust
> >>> the soname to include the sublevel version.
> >>>
> >>> This ma
Hi,
On Fri, Apr 23, 2010 at 8:36 PM, Kevin Day wrote:
>> > Since it seems that ld.so soname is hardcoded in GCC. If you want to
>> > use something else than /lib/ld-uClibc.so.0 as dynamic linker, you also
>> > need to update GCC default configration, create alternate specfile
>> > overriding
On Thursday 22 April 2010 05:10:41 Michael Deutschmann wrote:
> On Thu, 22 Apr 2010, Natanael Copa wrote:
> > Do you have any better suggestions how to upgrade a running system?
>
> First, build the new uClibc, but don't install it yet.
>
> Build a customized ld-uclibc.so.0, from the previous uClib
On Mon, 26 Apr 2010, Rob Landley wrote:
> > Build a customized ld-uclibc.so.0, from the previous uClibc source, that
> > looks in a different place for shared libraries and ignores the
> > /etc/ld.so.* files. Install it under a different filename.
>
> Or just build it that way in the first place..
On Friday 23 April 2010 09:29:10 Austin Foxley wrote:
> > Since it seems that ld.so soname is hardcoded in GCC. If you want to
> > use something else than /lib/ld-uClibc.so.0 as dynamic linker, you also
> > need to update GCC default configration, create alternate specfile
> > overriding the hardco
On Friday 23 April 2010 10:08:42 Timo Teräs wrote:
> Austin Foxley wrote:
> > On 04/23/2010 07:18 AM, Timo Teräs wrote:
> >> Austin Foxley wrote:
> >>> On 04/20/2010 07:49 AM, Natanael Copa wrote:
> Since sublevel releases are not ABI compatible we need to adjust
> the soname to include t
On 05/01/2010 05:47 PM, Rob Landley wrote:
On Friday 23 April 2010 09:29:10 Austin Foxley wrote:
Since it seems that ld.so soname is hardcoded in GCC. If you want to
use something else than /lib/ld-uClibc.so.0 as dynamic linker, you also
need to update GCC default configration, create alternate
Rob Landley wrote:
You're saying you want to support having two installations of uClibc the same
system. Starting from separate dynamic linkers, and going through segregated
library search paths. Because nothing says "lightweight and embedded" like
installing two or three complete copies of y
On Sun, 2 May 2010, Timo wrote:
> And yes, it's not full solution. Deep library wise dependencies can be
> temporarily broken.
The problem is that just one level of shared library other than the C
library, is sufficient to break side-by-side execution based *only* on C
library soname changes. Tha
On Sunday 02 May 2010 14:23:29 Timo Teräs wrote:
> Rob Landley wrote:
> > You're saying you want to support having two installations of uClibc the
> > same system. Starting from separate dynamic linkers, and going through
> > segregated library search paths. Because nothing says "lightweight and
Rob Landley wrote:
No, the idea is not to have two versions installed all the time. The idea
is to allow the coexistance temporarily while package manager is upgrading
system.
Isn't this what static linking is for?
If we targeted flashable upgrade, then this would not be needed as
everything
On Mon, May 03, 2010 at 08:14:38AM +0300, Timo Teräs wrote:
> Yes, static linking would be more bullet proof. But either the user, or
> the package manager needs jump through hoops in this case. There needs to
> be the static versions compiled, they need to get installed, then finally
> replaced wi
2010/5/3 Lennart Sorensen :
> On Mon, May 03, 2010 at 08:14:38AM +0300, Timo Teräs wrote:
>> Yes, static linking would be more bullet proof. But either the user, or
>> the package manager needs jump through hoops in this case. There needs to
>> be the static versions compiled, they need to get inst
On Mon, May 03, 2010 at 05:16:29PM +0200, Natanael Copa wrote:
> because you want avoid 10 times bigger binary? (alpine linux's
> apk-tools is 90k dynamic and 900k static due to libcrypto for
> hashing/signing)
Wow that does sound pretty big.
> Yes for upgrade, I'll probably recommend do that wit
> because you want avoid 10 times bigger binary? (alpine linux's
> apk-tools is 90k dynamic and 900k static due to libcrypto for
> hashing/signing)
So what? libcrypto obviously wasn't designed for embedded
environments. In fact, it's probably the most bloated free crypto
library around. If the Al
On Mon, May 3, 2010 at 8:11 PM, Laurent Bercot wrote:
> That's fine, as long as the support for ABI_VERSION does not impact
> code that does not use it. If statically linked code is somehow made less
> efficient by adding dynamic ABI_VERSION support, not everyone's happy.
> If the libc.so dynami
On Monday 03 May 2010 13:11:38 Laurent Bercot wrote:
> > because you want avoid 10 times bigger binary? (alpine linux's
> > apk-tools is 90k dynamic and 900k static due to libcrypto for
> > hashing/signing)
>
> So what? libcrypto obviously wasn't designed for embedded
> environments. In fact, it's
31 matches
Mail list logo
