Re: symbol versioning ORIG:(forw) Re: Upgrade nightmare
Andreas,
I'm not sure I understand what your question really is. I know that gcc
3.x requires a fairly new version of binutils. I've been having the best
results with 2.11.93.0.2-1. This version seems to have fixed the
problems I had with debugging symbols, and also seems to work correctly
with C++.
I don't know much about symbol versioning. AFAIK, it is only used by
libc and the kernel. I believe most libraries just use version numbers.
---Nathan
On Wed, Apr 17, 2002 at 11:27:45PM +0200, Andreas Schuldei wrote:
> i would like your advice on this. is symbol versioning required
> to be able to have nice upgradeabel libs as needed for debian
> packages of libs?
> From: Marc Espie <espie@nerim.net>
> To: "'misc@openbsd.org'" <misc@openbsd.org>
> Subject: Re: Upgrade nightmare
> Reply-To: espie@nerim.net
> Mail-Followup-To: "'misc@openbsd.org'" <misc@openbsd.org>
> X-Spam-Status: No, hits=0 required=5 tests=
>
> On Wed, Apr 17, 2002 at 11:47:53AM +0200, Andreas Schuldei wrote:
> > * Marc Espie (espie@nerim.net) [020417 01:28]:
> > > You are using the assembler from new-binutils, this is wrong.
> >
> > [...]
> >
> > > Except for us OpenBSD developers. Because you see, we went
> > > through the same nightmare before, when we slowly took the
> > > OS from 2.9 to 3.1... and most of the issues you are going
> >
> > Could you please give a short overview of what happend, where
> > we are today and what the goal is? Are we moving to some enhanced
> > ELF (OLF) and what can the new binutils do what the old could
> > not? I noticed that there are still library versioning problems
> > which are solved under linux. (just stumbled onto that...)
>
> We don't have library versioning problems. We are using a simpler
> scheme that just works. Tell me about what problems you think linux
> solves, and I tell you how we don't need it :)
>
> What the new binutils can do that we can't (yet):
> - support for new i386 asm instruction. That could probably be patched in.
> - elf sections, which means better support for debugging information
> (though it's not perfect yet, because the tools need to coalesce info
> more).
> - dwarf unwind info, for C++ exception support.
> - scripting. That can be used to handle ctors/dtors in better ways.
> - some obscure bugs in symbol handling in shared libraries (yes, in ld).
> - better memory usage for linking huge libraries (though the hack I've
> just committed to ld alleviates that problem a great deal).
> - in general, tighter cooperation with recent gcc releases. It's just
> a question of testing gcc and fixing the various bits that have been
> broken by the FSF recent releases, really.
> - -zcomb-reloc, though that isn't perfect yet. In general, pre-linking
> support is being worked on in very recent binutils. That's useful for
> coalescing relocation info better in large shared code-based projects (see
> the kde webpage for details)
>
> We also have issues which are completely separate from binutils proper.
> - some ld.so bugs, which probably kill mozilla.
> - gdb has troubles with a.out pic information.
> - thread support in general, and in particular in the C++ library and qt.
>
> One large problem is that binutils may work, but the code is a piece of
> junk. It is very convoluted, and it is very hard to find the piece of code
> that you are looking for. The patterns used to make the code very flexible
> are not at all apparent, and the various indirection mechanisms are very
> poorly documented (most of the bfd functions are undocumented, the ld
> scripting mechanism is poorly documented), and the functionality separation
> is poor (you often find operating-system specific stuff in supposedly
> arch-only files), plus there are lots of defines that contribute to
> obfuscating the code (hard to find out what's compiled in ELF/ECOFF/AOUT
> modes).
>
--
To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: