Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Nov 2002 19:13:52 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        ataraxia@cox.net, current@FreeBSD.ORG
Subject:   Re: [PATCH] note the __sF change in src/UPDATING
Message-ID:  <Pine.GSO.4.10.10211081904490.10745-100000@pcnet1.pcnet.com>
In-Reply-To: <20021108.161606.79869853.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Nov 2002, M. Warner Losh wrote:

> In message: <Pine.GSO.4.10.10211081806220.10745-100000@pcnet1.pcnet.com>
>             Daniel Eischen <eischen@pcnet1.pcnet.com> writes:
> : On Fri, 8 Nov 2002, M. Warner Losh wrote:
> : 
> : > In message: <Pine.GSO.4.10.10211081205020.27766-100000@pcnet1.pcnet.com>
> : >             Daniel Eischen <eischen@pcnet1.pcnet.com> writes:
> : > : All the ports are going to be rebuilt for the release anyways,
> : > : so this doesn't affect fresh installs, correct?  It is only a
> : > : problem when mixing older 4.x and 5.0 libraries/binaries with
> : > : __sF-free libc (if I understand things correctly).
> : > 
> : > The problem is that you cannot have 4.x packages and 5.x packages
> : > co-mingled on the same system.  that's what I'm trying to fix.  You'd
> : > have to rebuild the 4.x packages before they are fixed.
> : 
> : I don't think this is a show-stopper.  Just recompile all your
> : ports or use the pre-built 5.0 packages.
> 
> I disagree.

No problem :-)

> : > : This is 5.0; it is a major release and there will be some flies
> : > : in the ointment.  I say bite the bullet now -- don't wait.
> : > : If we want to provide an optional compatability hack to libc
> : > : so that folks can compile it with __sF support, then I think
> : > : that is better than leaving __sF in the release, perhaps
> : > : with a mktemp(3)-like warning if possible (?).
> : > 
> : > You'd need a run-time warning for this to be effective.  I'm not sure
> : > that ld.so can do this right now.
> : 
> : Could you put __sF in it's own file, and put the error in
> : a .init section?  We don't care about static binaries, right?
> : They shouldn't have a problem.
> 
> More details please.  I'd love for there to be a way to know which
> binaries use __sF.

I'm not even close to a shared library/linker expert, but
I thought there was a way to have something run when an
object file got loaded.  From rtld(1):

  After all shared libraries have been successfully loaded, ld-elf.so.1
  proceeds to resolve external references from both the main program and
  all objects loaded. A mechanism is provided for initialization routines
  to be called on a per-object basis, giving a shared object an opportunity
  to perform any extra set-up before execution of the program proper
  begins.  This is useful for C++ libraries that contain static construc-
  tors.

If you put __sF in it's own file with whatever is needed for
the above, won't that work?

-- 
Dan Eischen


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10211081904490.10745-100000>