Here is a plan on how to do so. It requires to modify dpkg but allows
complete compatibility and no breakage of binaries (building with
G++-2.95 would no longer work unless wrappers are written).
1. Create a new version of dpkg that does the following;
In the postinst script it checks whether /us
> HAHAHAHAHA. No.
>
> .__.
> _|doogie|_ <-- dpkg hat
>
No because of technical reasons, or because it's too much work?
IMHO since changing library filenames breaks compatibility with other
distributions, this is the only way to allow installation of old
packages (that, still IMHO, must abs
I forgot an important thing: all new non-C++ packages should be tagged
as non-C++ in some way so that dpkg doesn't need to scan them.
This should of course be done by having the build tools scan the package
build directory and set either a new field ('Uses-C++-ABI: No') or by
dependency on the new
> Because you have no clue what you are talking about.
The problem is that people who have a clue are proposing solutions that
would break existing packages and would cause the user to recompile
everything he has compiled on his own.
Furthermore, they don't explain what is wrong with the approach
> No because it is overcomplicated
This isn't a problem for you, I'm doing the work (I have already managed
to write a program to detect the ABI, a wrapper generator and patched
dpkg to move libraries; I still have to do shlibs support and hook the
wrapper generator to dpkg).
If it isn't accepted,
On Sun, 2002-08-18 at 17:47, Steve Langasek wrote:
> On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote:
> > > No because it is overcomplicated
> > This isn't a problem for you, I'm doing the work (I have already managed
> > to write a program to detec
> I certainly prefer NOT doing any ugly stuff with dpkg.
> "apt-get dist-upgrade" will uninstall packages that havn't been updated
> to the new c++ yet, which certainly is worth a bug report on these
> packages...
Oops, I meant upgrade not dist-upgrade. dist-upgrade is bad :)
> That is exactly the
On Sun, 2002-08-18 at 20:08, Erich Schubert wrote:
> > > hacking the dynamic linker certainly is better than that...
> > This only allows to avoid creating wrappers but doesn't avoid the
> > problem that two libraries can't have the same filename.
> > Something (dpkg) must move one of them.
>
> No
> > > > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do
> > > > so when the transition is complete, there will still be non-Debian G++
> > > > v2 packages installed on users' machines.
> > >
> > > No, they are not, as long as there are dependency problems, and as long
> >
According to Junichi's manual they should be in -dev packages (that
makes sense, since they are only used by libtool builds).
The following packages might be affected. The list only includes
packages from unstable in libs/ with digits in the name.
hamlib1
kdelibs3
kdelibs3-cups
libaspell10
libcap
> ltdl needs them at runtime.
If so, how should parallel installation be handled?
How does one decide whether the .la file should be put in the main
package or the dev one?
The shared library packaging manual should be updated to included this
information if this is the case.
signature.asc
Des
I've managed to patch both dpkg and glibc.
However the resulting system does not work because some things like KDE
use absolute paths so they would too need to be fixed.
Furthermore, we have the problem of C++ library packages including
non-C++ files. This can only be handled by heavily modifying
I propose to do the following to solve the libpng2/3 problem. I've
recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
seems to work correctly.
1. Recompile libpng2 and libpng3 with -Bsymbolic
2. Recompile all libraries that use either libpng2 or libpng3 to
On Tue, 2002-08-20 at 21:46, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > I propose to do the following to solve the libpng2/3 problem. I've
> > recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
> &g
> using -Bsymbolic ensures that whenever the libpng library makes a call to
> one of its own functions, the symbol is resolved internally instead of to
> another version of libpng that's loaded. This may account for a majority
> of the segfaults that people are seeing. It does not affect how symb
Yes, you are right, by reading at the source it seems that ld.so only
searches the object with -Bsymbolic.
In fact there is this comment in the relevant file:
/* Create an appropriate searchlist. It contains only this map.
XXX This is the definition of DT_SYMBOLIC in SysVr4. The
On Tue, 2002-08-20 at 23:02, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > Apparently the "different interpretation" is what I was assuming the
> > current one.
>
> Yeah, I was in a severe headache for a while because I too knew
On Tue, 2002-08-20 at 23:28, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > Why?
> > Can't we just use it in Debian?
>
> Are you mad? What happens if the ELF format or gnu upstream start using that
> value for something else?
On Tue, 2002-08-20 at 23:28, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > Why?
> > Can't we just use it in Debian?
>
> Are you mad? What happens if the ELF format or gnu upstream start using that
> value for something else?
I f
On Tue, 2002-08-20 at 23:56, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > On Tue, 2002-08-20 at 23:28, Henrique de Moraes Holschuh wrote:
> > > On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > > > Why?
> > > > Can't
This is a proposal (including patches) for a GNU extension to the ELF
executable format that adds a flag that causes the dynamic loader to
start searching for symbols referenced by modules with the flag set from
the module itself and its immediate dependencies. If the symbol is not
found in this wa
On Wed, 2002-08-21 at 19:13, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Torsten Landschoff wrote:
> > Just explain why it is the right thing to do. And I would like to stay
> > binary compatible with RedHat etc. if at all possible.
>
> Well, apps like to be able to use libsasl, and
On Thu, 2002-08-22 at 00:11, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Luca Barbieri wrote:
> > This is an another problem that would be easily and compatibly solved by
> > my ELF extension (until the library gets properly fixed upstream).
>
> Yes and no.
I forgot to consider what happens when a Debian-built versioned binary
is used with a non-Debian no-versioned library.
Here is Drepper's explanation:
The last case is if the object with the references uses symbol
versions but the object with the definitions has none. In this case a
matching symbo
Yes, unfortunately that situation triggers an assert... what a great
feature :(
So apart from the need to remove the unversioned-uses-versioned error,
we also to produce unversioned binaries.
The simplest way to this is is IMHO to add a /usr/lib/dev directory and
make it the first directory searc
Both problems can be solved by simply writing the version scripts so
that only a version tag is mentioned in each:
libpng2.ver:
LIBPNG_2.0 {global: png_*);
libpng3.ver:
LIBPNG_3.0 {global: png_*);
However, we'll still get a warning message if versioned binaries are
used with unversioned libraries
This an alternative solution to the -Bsymbolic/-Blocal approach that I
exposed before. It doesn't require any loader/linker code modifications
but requires more work by the library maintainers and is better done
with upstream consensus (but this isn't strictly necessary).
First, we must define ver
On Thu, 2002-08-22 at 08:13, Roland McGrath wrote:
> I think you can get the effect you need just by using -Bsymbolic. In your
> example, build the GTK+ library with -Bsymbolic. If that causes problems
> because some of the library's references should be resolved in the normal
> global scope, the
> Hmm, what if two functions which get imported from different versions of
> the same library operate on a static (private to the library) variable
> that is needed for a proper operation for some reason? You'd better
> rebuild the sources to use a single version of each library instead.
I don't
On Thu, 2002-08-22 at 11:23, Jakub Jelinek wrote:
> On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote:
> > On 21 Aug 2002, Luca Barbieri wrote:
> >
> > > This is a proposal (including patches) for a GNU extension to the ELF
> > > executable format
On Thu, 2002-08-22 at 21:35, Maciej W. Rozycki wrote:
> On 22 Aug 2002, Luca Barbieri wrote:
>
> > > Hmm, what if two functions which get imported from different versions of
> > > the same library operate on a static (private to the library) variable
> > > that
> Then you have to deal with consistency issues. They do not exist for
> self-contained libraries that act locally only like png, but they may
> arise with libraries that interact with the outer world, e.g. any that
> makes use of networking. For example using different versions of the X11
> lib
On Mon, 2002-08-26 at 17:57, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Aug 2002, Luca Barbieri wrote:
> > Both problems can be solved by simply writing the version scripts so
> > that only a version tag is mentioned in each:
> > libpng2.ver:
> > LIBPNG_2.0 {globa
33 matches
Mail list logo
