Progress on roadmap to 0.9.13

Progress on roadmap to 0.9.13

[Rich Felker]

Progress towards 0.9.13 is pretty much on-schedule. The
cpuset/affinity, arm memcpy, and iconv kr/tw/hk tasks are mostly
complete. nsz is working on the 387 math asm task, and I've started on
the getaddrinfo and legacy resolver functions task. I still need to do
all the work on strftime field widths; that's untouched so far. So are
most of the secondary targets.

One key target for 0.9.13 which I didn't cover above is improving
"make install" and possibly tweaking the symlink strategy for libc.so
and ld-musl.so. At several times in the past, I was fairly convinced
that it makes more sense to reverse the symlink direction and have
libc.so point to ld-musl.so rather than the other way around. However,
I keep going back to doubting that there's any good reason for it to
change. So if there are people who still care about this issue, I'd
really like to hear you speak up _now_ rather than 2 days before the
next release, or after the next release. If there's no progress on
justifying changes, I think the only changes I'm going to make in this
area are to fix lack-of-atomicity issues during installation.

Today, August 15, puts us at the beginning of the projected release
window for 0.9.13; any time in the next two weeks would still be well
within the window, and I think that's still a viable goal. If some key
targets get left out of this release, I may aim to add one more step
in the roadmap before 1.0, but I hope to avoid doing that.

One thing that's not in the current roadmap is additional ports. The
possibility of additional ports in any of the upcoming releases (even
1.0 as long as the new ports are labeled experimental) is something
I've had in mind for a long time, but as I'm probably not going to
have time to spend on ports in addition to meeting the rest of the
goals I have, the bulk of the work on additional ports would need to
come from other contributors.

Rich

Re: Progress on roadmap to 0.9.13

[Rob Landley]

On 08/15/2013 02:59:12 AM, Rich Felker wrote:
> One key target for 0.9.13 which I didn't cover above is improving
> "make install" and possibly tweaking the symlink strategy for libc.so
> and ld-musl.so. At several times in the past, I was fairly convinced
> that it makes more sense to reverse the symlink direction and have
> libc.so point to ld-musl.so rather than the other way around. However,
> I keep going back to doubting that there's any good reason for it to
> change. So if there are people who still care about this issue, I'd
> really like to hear you speak up _now_ rather than 2 days before the
> next release, or after the next release.

Which makes it easier to install uClibc and musl and bionic next to  
each other? (You can have /lib/musl and /lib/uClibc and /lib/bionic for  
most of the .so and .a files, but the dynamic linker is a hardwired  
abspath in each binary and then the linker would be what searches the  
more specific path...)

> One thing that's not in the current roadmap is additional ports. The
> possibility of additional ports in any of the upcoming releases (even
> 1.0 as long as the new ports are labeled experimental) is something
> I've had in mind for a long time, but as I'm probably not going to
> have time to spend on ports in addition to meeting the rest of the
> goals I have, the bulk of the work on additional ports would need to
> come from other contributors.

Real life continues to intrude into my schedule, but I'm slowly working  
towards this. Until musl supports all the targets aboriginal does now,  
I can't drop uClibc support, and klibc has some code I can start with  
to get to "hello world" level...

Rob

Re: Progress on roadmap to 0.9.13

[Rich Felker]

On Fri, Aug 16, 2013 at 01:21:10AM -0500, Rob Landley wrote:
> On 08/15/2013 02:59:12 AM, Rich Felker wrote:
> >One key target for 0.9.13 which I didn't cover above is improving
> >"make install" and possibly tweaking the symlink strategy for libc.so
> >and ld-musl.so. At several times in the past, I was fairly convinced
> >that it makes more sense to reverse the symlink direction and have
> >libc.so point to ld-musl.so rather than the other way around. However,
> >I keep going back to doubting that there's any good reason for it to
> >change. So if there are people who still care about this issue, I'd
> >really like to hear you speak up _now_ rather than 2 days before the
> >next release, or after the next release.
> 
> Which makes it easier to install uClibc and musl and bionic next to
> each other? (You can have /lib/musl and /lib/uClibc and /lib/bionic
> for most of the .so and .a files, but the dynamic linker is a
> hardwired abspath in each binary and then the linker would be what
> searches the more specific path...)

Makes no difference. Either way, the dynamic linker is intended to be
in /lib and everything else can be wherever you want it to be.

Rich

Re: Progress on roadmap to 0.9.13

[Timo Teras]

On Thu, 15 Aug 2013 03:59:12 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> One key target for 0.9.13 which I didn't cover above is improving
> "make install" and possibly tweaking the symlink strategy for libc.so
> and ld-musl.so. At several times in the past, I was fairly convinced
> that it makes more sense to reverse the symlink direction and have
> libc.so point to ld-musl.so rather than the other way around. However,
> I keep going back to doubting that there's any good reason for it to
> change. So if there are people who still care about this issue, I'd
> really like to hear you speak up _now_ rather than 2 days before the
> next release, or after the next release. If there's no progress on
> justifying changes, I think the only changes I'm going to make in this
> area are to fix lack-of-atomicity issues during installation.

Sorry for late answer.

IIRC the advantages were:

- Easier to install different subarch (even compatible arch versions)
  side by side. As ld.so names are unique - libc.so is same for all so
  those would need to be renamed anyway.

- libc.so and libc.a can go to /usr/lib if libc.so is just an
  optional symlink. this is desirable as the development stuff are not
  nice to keep in /lib.

So I would at least like to have the symlink direction changed.

Or alternatively have something like:
  /lib/libc-arch.so.<abiver>
  /lib/ld-musl-<arch>.so.1 -> libc-arch.so.<abiver
  /usr/lib/libc.so -> /lib/libc.so.<abiver>
  /usr/lib/libc.a

Allowing of course /usr/lib to be a toolchain specific prefix.

- Timo

Re: Progress on roadmap to 0.9.13

[Matias A. Fonzo]

Hello,

El Sat, 17 Aug 2013 12:39:13 +0300
Timo Teras <timo.teras@iki.fi> escribió:
> On Thu, 15 Aug 2013 03:59:12 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > One key target for 0.9.13 which I didn't cover above is improving
> > "make install" and possibly tweaking the symlink strategy for
> > libc.so and ld-musl.so. At several times in the past, I was fairly
> > convinced that it makes more sense to reverse the symlink direction
> > and have libc.so point to ld-musl.so rather than the other way
> > around. However, I keep going back to doubting that there's any
> > good reason for it to change. So if there are people who still care
> > about this issue, I'd really like to hear you speak up _now_ rather
> > than 2 days before the next release, or after the next release. If
> > there's no progress on justifying changes, I think the only changes
> > I'm going to make in this area are to fix lack-of-atomicity issues
> > during installation.
> 
> Sorry for late answer.
> 
> IIRC the advantages were:
> 
> - Easier to install different subarch (even compatible arch versions)
>   side by side. As ld.so names are unique - libc.so is same for all so
>   those would need to be renamed anyway.
> 
> - libc.so and libc.a can go to /usr/lib if libc.so is just an
>   optional symlink. this is desirable as the development stuff are not
>   nice to keep in /lib.
> 

This does not seem viable if /usr is a symlink / or /usr/lib is a
symlink to /lib. /opt can be the place ...

Regards,
Matias

Re: Progress on roadmap to 0.9.13

[orc]

On Sat, 17 Aug 2013 12:39:13 +0300
Timo Teras <timo.teras@iki.fi> wrote:

> On Thu, 15 Aug 2013 03:59:12 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > One key target for 0.9.13 which I didn't cover above is improving
> > "make install" and possibly tweaking the symlink strategy for
> > libc.so and ld-musl.so. At several times in the past, I was fairly
> > convinced that it makes more sense to reverse the symlink direction
> > and have libc.so point to ld-musl.so rather than the other way
> > around. However, I keep going back to doubting that there's any
> > good reason for it to change. So if there are people who still care
> > about this issue, I'd really like to hear you speak up _now_ rather
> > than 2 days before the next release, or after the next release. If
> > there's no progress on justifying changes, I think the only changes
> > I'm going to make in this area are to fix lack-of-atomicity issues
> > during installation.
> 
> Sorry for late answer.
> 
> IIRC the advantages were:
> 
> - Easier to install different subarch (even compatible arch versions)
>   side by side. As ld.so names are unique - libc.so is same for all so
>   those would need to be renamed anyway.
> 
> - libc.so and libc.a can go to /usr/lib if libc.so is just an
>   optional symlink. this is desirable as the development stuff are not
>   nice to keep in /lib.
> 
> So I would at least like to have the symlink direction changed.
> 
> Or alternatively have something like:
>   /lib/libc-arch.so.<abiver>
>   /lib/ld-musl-<arch>.so.1 -> libc-arch.so.<abiver
>   /usr/lib/libc.so -> /lib/libc.so.<abiver>
>   /usr/lib/libc.a
> 
> Allowing of course /usr/lib to be a toolchain specific prefix.
> 
> - Timo

I generally don't like the idea of symlink change, but if it will go, I
will not argue. But, how existing installs will resolve that change
in one pass during install? Do I need static busybox to manually
replace symlink?
I even suggest making a hard link between them, so no symlink issue
will be there :)
It requires a bit more work without benefit. Point me please to
benefits page/mail, because I lost in my imap cache.

Re: Progress on roadmap to 0.9.13

[Rich Felker]

On Sat, Aug 17, 2013 at 11:39:43PM +0800, orc wrote:
> I generally don't like the idea of symlink change, but if it will go, I
> will not argue. But, how existing installs will resolve that change
> in one pass during install? Do I need static busybox to manually
> replace symlink?

No, replacing the direction or even changing it back to how it is now
should be safe as long as the actual-file is installed first and the
link is installed after that. The current rules should provide that
behavior. However I believe the atomicity of installing the actual
file is still broken right now: it seems the old file is being
overwritten rather than replaced. I'll check that and fix it if it's
still the case.

Rich

Re: Progress on roadmap to 0.9.13

[Christian Neukirchen]

orc <orc@sibserver.ru> writes:

> I generally don't like the idea of symlink change, but if it will go, I
> will not argue. But, how existing installs will resolve that change
> in one pass during install? Do I need static busybox to manually
> replace symlink?

/usr/bin/sln is owned by glibc 2.18-1

DESCRIPTION
       The  sln  program creates symbolic links.  Unlike the ln(1) program, it
       is statically linked.  This means that if for some reason  the  dynamic
       linker  is  not  working,  sln  can  be  used to make symbolic links to
       dynamic libraries.

*scnr*
-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Progress on roadmap to 0.9.13

[Rich Felker]

On Sat, Aug 17, 2013 at 12:39:13PM +0300, Timo Teras wrote:
> On Thu, 15 Aug 2013 03:59:12 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > One key target for 0.9.13 which I didn't cover above is improving
> > "make install" and possibly tweaking the symlink strategy for libc.so
> > and ld-musl.so. At several times in the past, I was fairly convinced
> > that it makes more sense to reverse the symlink direction and have
> > libc.so point to ld-musl.so rather than the other way around. However,
> > I keep going back to doubting that there's any good reason for it to
> > change. So if there are people who still care about this issue, I'd
> > really like to hear you speak up _now_ rather than 2 days before the
> > next release, or after the next release. If there's no progress on
> > justifying changes, I think the only changes I'm going to make in this
> > area are to fix lack-of-atomicity issues during installation.
> 
> Sorry for late answer.
> 
> IIRC the advantages were:
> 
> - Easier to install different subarch (even compatible arch versions)
>   side by side. As ld.so names are unique - libc.so is same for all so
>   those would need to be renamed anyway.

I don't see how this would help. If you have multiple incompatible
ABIs present on a system, each one needs its own separate library
dirs, both for development libraries and runtime libraries. Thus each
dir can have its own libc.so without affecting the others. (libc.so is
not special in this way; the same applies to non-system libraries like
libz.so, etc. as well.)

> - libc.so and libc.a can go to /usr/lib if libc.so is just an
>   optional symlink. this is desirable as the development stuff are not
>   nice to keep in /lib.

Are you talking about the case where /usr is a separate partition not
mounted at first?

> So I would at least like to have the symlink direction changed.
> 
> Or alternatively have something like:
>   /lib/libc-arch.so.<abiver>
>   /lib/ld-musl-<arch>.so.1 -> libc-arch.so.<abiver
>   /usr/lib/libc.so -> /lib/libc.so.<abiver>
>   /usr/lib/libc.a
> 
> Allowing of course /usr/lib to be a toolchain specific prefix.

This works, but I'm unclear on how it would be better than the current
situation, except for the partitions issue. It does seem worse in one
way: that libc-arch.so.1 could get accidentally linked against and
included in DT_NEEDED. This could be avoided by varying the name
slightly, e.g. libc.arch.so.1, I think.

Rich