> 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, [EMAIL PROTECTED]
#!/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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
