[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: S-Lang for use with libc6 uploaded (source, i386)

> I'm replying to this on debian-devel since many developers are
> probably still not clear on the issues that come up when converting to
> libc6.

Thanks, it's good to read this!

> On Jun 4, J.H.M. Dassen wrote
> >    * Non-maintainer release (OK-ed by Chris); slang should now be usable
> >      with libc6.
> Ray, converting a library to libc6 is not this simple.  Only the most
> trivial of libraries can actually be built to work both libc5 and
> libc6 at the same time.  Because of this, we need to provide separate
> slang libraries for libc5 and libc6.
> Because the current slang0.99.34 and slang0.99.34-dev packages are
> implicitly for libc5, we can't "re-use" them and therefore need to use
> new package names for the new libc6 versions.  I've been recommending
> people simply append a "g" to the package names in these cases to
> identify them as being for glibc/libc6.  The new packages might then
> be slang0.99.34g and slang0.99.34g-dev.

With libg++, I noticed that the upstream, version, patched by
HJ Lu for glibc, had a new soname (it's 272 now, was 27). So, I called
the glibc compiled libg++ package "libg++272" (libc5: libg++27).
Do you think this was a good idea? If not, should I change it to
libg++272g? (even though some packages already may depend on libg++272,
I don't know).

> Making separate packages for libc5 and libc6 creates two problems
> because both libraries will use the same file names and sonames.
> First, the libraries can't be in the same directory as each other.  To
> solve this problem, the current libc5 package provides two new
> directories, /lib/libc5-compat and /usr/lib/libc5-compat.  These can
> be used to put old libc5-based libraries which conflict with new
> libc6-based ones.

So, that means my libg++27 package (the old one) should be updated
to put it's shared libs in /usr/libc5-compat, right? At the moment,
it doesn't do so, but I don't have problems with that -- probably
because of the different sonames I'm using. Should I still put the
libc5-compat stuff in the right place?

> Second, the dynamic linkers need to be able to determine which
> libraries are for libc5 and which are for libc6.  To facilitate this,
> each library must contain a run-time dependency on at least one of
> libc, libm and libdl.

$ ldd /usr/lib/libg++.so.272.5.0 
        libstdc++.so.272 => /usr/lib/libg++-dbg/libstdc++.so.272 (0x4003c000)

So, I'm wrong here too? Does that mean I didn't have the same libc6-dev
version installed as libc6 version? If I recompile libg++272 now, will
it be fixed (I've got it correct now, I *though* I had it correct at
the time too). Did I do something else wrong? (And, why don't I notice
any problems -- well never mind, that must be because ldso is so clever).

$ dpkg -l libc6*
ii libc6     2.0.3-4  The GNU C library version 2 (run-time files)
ii libc6-dbg 2.0.3-4  The GNU C library version 2 (debugging/profi
ii libc6-dev 2.0.3-4  The GNU C library version 2 (development fil
ii libc6-doc 2.0.3-4  The GNU C library version 2 (documentation f

In short, thanks for the clarification. I hope I didn't mess up too badly
with libg++, and I havent had/seen any problems yet from my packages, but
with your post, I'm not too sure any more.

joost witteveen, joostje@debian.org
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: