Loren James Rittle wrote:
> > FWIW: symbol versioning is incredibly broken. It attempts to
> > do in UNIX what interface versioning does in Windows, through
> > the use of class factories accessed via IUnknown.
>
> You might be absolutely correct in general. However, please read
> http://gcc.gnu
Loren James Rittle wrote:
> FYI, the libstdc++-v3 maintainers on the FSF side are only
> guaranteeing forward ABI compatibility of any sort if libstdc++.so is
> built with symbol versioning and symbol hiding.
FWIW: symbol versioning is incredibly broken. It attempts to
do in UNIX what interface v
Doug Rabson wrote:
> In the windows world, all this is handled by having a strict list of explicit
> symbol exports, either in the source code using syntax extensions or with a
> file supplied to the linker. I'm not sure whether binutils supports this kind
> of thing but it would allow us to cut
In message: <[EMAIL PROTECTED]>
Sheldon Hearn <[EMAIL PROTECTED]> writes:
: If the final word on this whole issue is "You can't run binaries
: compiled for 4.x-RELEASE on 5.x-RELEASE" then we should start puckering
: up.
:
: Developers tend to remember these things and you don't have t
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: If you can't agree on a coordinate system ("OLDCARD? NEWCARD?
: REDCARD? BLUECARD?"), then at least agree to get rid of data
: interfaces;
Ironically, NEWCARD and OLDCARD are driver compatible because it
doesn
Doug Rabson wrote:
> The kernel ABI is hopeless. It changes almost daily :-(. At one time, I
> thought I could change this but these days, I don't think anyone except
> me cares about having a stable ABI in the kernel.
I care. It's almost the most important thing to be able to build
anything of v
On Saturday 09 November 2002 4:28 pm, Daniel Eischen wrote:
> On Sat, 9 Nov 2002, Doug Rabson wrote:
> > On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote:
> > > On Fri, 8 Nov 2002, M. Warner Losh wrote:
> > > > This is not a fly in the pointment, but rather a major
> > > > incompatibility
On Sat, 9 Nov 2002, Doug Rabson wrote:
> On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote:
> > On Fri, 8 Nov 2002, M. Warner Losh wrote:
> > > This is not a fly in the pointment, but rather a major
> > > incompatibility that makes it impossible to have a reasonable mix.
> >
> > If it's re
On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote:
> On Fri, 8 Nov 2002, M. Warner Losh wrote:
> > In message:
> > <[EMAIL PROTECTED]>
> >
> > Daniel Eischen <[EMAIL PROTECTED]> writes:
> > : All the ports are going to be rebuilt for the release anyways,
> > : so this doesn't af
On (2002/11/08 18:13), Daniel Eischen wrote:
> > 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
In message: <[EMAIL PROTECTED]>
Brooks Davis <[EMAIL PROTECTED]> writes:
: On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
: > I'd love for there to be a way to know which binaries use __sF.
:
: The following script run on your bin, sbin, lib, and libexec directories
:
At 6:13 PM -0500 11/8/02, Daniel Eischen wrote:
On Fri, 8 Nov 2002, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: All the ports are going to be rebuilt for the release anyways,
: so this doesn't affect fresh installs, correct?
On Fri, Nov 08, 2002 at 05:05:23PM -0800, Brooks Davis wrote:
> On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
> > I'd love for there to be a way to know which binaries use __sF.
>
> The following script run on your bin, sbin, lib, and libexec directories
> does a pretty decent jo
On Fri, Nov 08, 2002 at 05:22:13PM -0800, [EMAIL PROTECTED] wrote:
> BTW, I did remove the $ from $*. I thought it was running too fast :-)
You're supposed to pass it a list of files not run it in a directory.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerpr
Quoting Brooks Davis <[EMAIL PROTECTED]>:
| On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
| > I'd love for there to be a way to know which binaries use __sF.
|
| The following script run on your bin, sbin, lib, and libexec directories
| does a pretty decent job of finding f
On Fri, Nov 08, 2002 at 04:16:06PM -0700, M. Warner Losh wrote:
> I'd love for there to be a way to know which binaries use __sF.
The following script run on your bin, sbin, lib, and libexec directories
does a pretty decent job of finding files that contain refrences to __sF
and listing the ports
Daniel Eischen wrote:
> 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 referenc
On Fri, 8 Nov 2002, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> : On Fri, 8 Nov 2002, M. Warner Losh wrote:
> :
> : > In message: <[EMAIL PROTECTED]>
> : > Daniel Eischen <[EMAIL PROTECTED]> writes:
> : > : All the
In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: On Fri, 8 Nov 2002, M. Warner Losh wrote:
:
: > In message: <[EMAIL PROTECTED]>
: > Daniel Eischen <[EMAIL PROTECTED]> writes:
: > : All the ports are going to be rebuilt for the release anyways,
:
On Fri, 8 Nov 2002, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> 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.
"M. Warner Losh" wrote:
> My plan is as follows:
>
> 1) Restore __sF to libc for 5.0.
> 2) Fix 4.x binaries so that __sF isn't referened in new
>binaries. This should have been done in Aug 2001, but
>wasn't.
>
> Depending on how things go, __sF will be rem
Andrew Kenneth Milton wrote:
> +---[ Steve Kargl ]--
> |
> | I agree with Dan. Let's do it now. My understanding is
> | that 5.0 will be an "early adopter" release and production
> | systems should run 4.7{8,9,..} until 5.1 is released.
> |
> | To accomplish the change, I
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: Here's the fun part. The following 5.0 libraries have the same
: version number as their 4.x counterparts. Try running a 4.x
: app linked against one of these libaries on a 5.0 machine. You
: should also note t
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: On Fri, Nov 08, 2002 at 12:17:00PM -0500, Daniel Eischen wrote:
: > On Fri, 8 Nov 2002, M. Warner Losh wrote:
: >
: > >
: > > Yes, but this is too painful. If we were going to do this, the time
: > > for the pa
In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> 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 (i
On Sat, Nov 09, 2002 at 04:16:11AM +1000, Andrew Kenneth Milton wrote:
>
> 6. Assume Crash Position.
>
Thanks for your important contribution to a discussion
which is addressing a rather serious problem. Here's the
important part of the "Ghost..." thread.
The following 4.7 libs make reference
+---[ Steve Kargl ]--
|
| I agree with Dan. Let's do it now. My understanding is
| that 5.0 will be an "early adopter" release and production
| systems should run 4.7{8,9,..} until 5.1 is released.
|
| To accomplish the change, I think we need to do:
| 1. Install a comp
On Fri, Nov 08, 2002 at 12:17:00PM -0500, Daniel Eischen wrote:
> On Fri, 8 Nov 2002, M. Warner Losh wrote:
>
> >
> > Yes, but this is too painful. If we were going to do this, the time
> > for the pain was 6-9 months ago, not just before the release.
>
> All the ports are going to be rebuilt f
> : > Subject: Re: [PATCH] note the __sF change in src/UPDATING
> : > From: "M. Warner Losh" <[EMAIL PROTECTED]>
> : >
> : > In message: <[EMAIL PROTECTED]>
> : > Ray Kohler <[EMAIL PROTECTED]> writes:
> : > : Hear hear,
> From [EMAIL PROTECTED] Fri Nov 8 11:30:05 2002
> Date: Fri, 08 Nov 2002 09:27:32 -0700 (MST)
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] note the __sF change in src/UPDATING
> From: "M. Warner Losh" <[EMAIL PROTECTED]>
In message: <[EMAIL PROTECTED]>
Ray Kohler <[EMAIL PROTECTED]> writes:
: > From [EMAIL PROTECTED] Fri Nov 8 02:45:04 2002
: > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST)
: > To: [EMAIL PROTECTED]
: > Subject: Re: [PATCH] note the __sF change in src/UPDATING
:
Doug Rabson wrote:
> > It _would_ be a good idea to document any internal library
> > symbols used by macros. Removing such symbols is a
> > good way to break existing compiled applications.
> >
> > Library design involves a lot of tradeoffs.
>
> In the windows world, all this is handled by havin
> From [EMAIL PROTECTED] Fri Nov 8 02:45:04 2002
> Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST)
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] note the __sF change in src/UPDATING
> From: "M. Warner Losh" <[EMAIL PROTECTED]>
>
> In message: <[EMAIL PROT
On Thursday 07 November 2002 9:42 pm, Tim Kientzle wrote:
> Terry Lambert asked:
> > Any chance we could get rid of all externally visable symbols that
> > are not defined as being there by some standard, and not just __sF,
> > since we are breaking the FORTRAN compiler and other third party
> > co
"M. Warner Losh" wrote:
> -current already does this. The problem is that we're trying to shoot
> the bad access in the head, and that is what is screwing people. So
> the problem isn't that we're trying to export private data to the
> world. Quite the contrary, we're trying to eliminate it and
In message: <[EMAIL PROTECTED]>
Ray Kohler <[EMAIL PROTECTED]> writes:
: Hear hear, I agree. There's no need to expose what ought to be
: "private" data to the world, especially when we can get the additional
: benefit here of letting us play with the implementation.
-current already d
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > Gotcha. I'm thinking very seriously about keeping __sF support (but
: > creating no new binaries with it in it) and the freeze on sizeof(FILE)
: > through the 5.x series of releases
> From [EMAIL PROTECTED] Thu Nov 7 18:30:04 2002
> Date: Thu, 07 Nov 2002 15:26:57 -0800
> From: Terry Lambert <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] note the __sF change in src/UPDATING
>
>
> Specifically, I do
"M. Warner Losh" wrote:
> Gotcha. I'm thinking very seriously about keeping __sF support (but
> creating no new binaries with it in it) and the freeze on sizeof(FILE)
> through the 5.x series of releases because we botched the
> compatibility stuff so badly to give people a chance to catch their
>
Tim Kientzle wrote:
> Terry Lambert asked:
> > Any chance we could get rid of all externally visable symbols that
> > are not defined as being there by some standard, and not just __sF,
> > since we are breaking the FORTRAN compiler and other third party
> > code already?
>
> This cannot be entire
In article <[EMAIL PROTECTED]>,
M. Warner Losh <[EMAIL PROTECTED]> wrote:
> In message: <[EMAIL PROTECTED]>
> John Polstra <[EMAIL PROTECTED]> writes:
> :
> : It's not CVSup, it's Modula-3. It thinks it knows that stdin,
> : stdout, and stderr are defined as above, but they're not any
In message: <[EMAIL PROTECTED]>
John Polstra <[EMAIL PROTECTED]> writes:
: In article <[EMAIL PROTECTED]>,
: M. Warner Losh <[EMAIL PROTECTED]> wrote:
: > In message: <[EMAIL PROTECTED]>
: > John Polstra <[EMAIL PROTECTED]> writes:
: >
: > : FWIW, the only OS fix that will m
Terry Lambert asked:
Any chance we could get rid of all externally visable symbols that
are not defined as being there by some standard, and not just __sF,
since we are breaking the FORTRAN compiler and other third party
code already?
This cannot be entirely done if you still want to
manage lib
In article <[EMAIL PROTECTED]>,
M. Warner Losh <[EMAIL PROTECTED]> wrote:
> In message: <[EMAIL PROTECTED]>
> John Polstra <[EMAIL PROTECTED]> writes:
>
> : FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
> : -current is to make __sF global again and arrange for:
In article <[EMAIL PROTECTED]>,
Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 07, 2002 at 09:35:19AM -0800, John Polstra wrote:
> > That would surprise me, but I haven't tried it myself. Inspection
> > of the ezm3 bootstrap shows that it has references to __sF.
> >
>
> Well, I just pkg_d
On Thu, Nov 07, 2002 at 09:35:19AM -0800, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Kargl <[EMAIL PROTECTED]> wrote:
> > On Thu, Nov 07, 2002 at 09:21:53AM -0800, John Polstra wrote:
> > > It's possible that if you already have a working installation of pm3
> > > or ezm3, you'l
In message: <[EMAIL PROTECTED]>
John Polstra <[EMAIL PROTECTED]> writes:
: In article <[EMAIL PROTECTED]>,
: M. Warner Losh <[EMAIL PROTECTED]> wrote:
: > In message: <[EMAIL PROTECTED]>
: > "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
: > : Could someone add the following
In article <[EMAIL PROTECTED]>,
Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 07, 2002 at 09:21:53AM -0800, John Polstra wrote:
> > It's possible that if you already have a working installation of pm3
> > or ezm3, you'll be able to build CVSup on -current. But if you try to
> > build pm3 o
On Thu, Nov 07, 2002 at 09:21:53AM -0800, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Kargl <[EMAIL PROTECTED]> wrote:
>
> > I rebuilt cvsup from net/cvsup yesterday on a new world, and
> > it appears to be working fine. What problems should I expect?
>
> It's possible that if
In article <[EMAIL PROTECTED]>,
Steve Kargl <[EMAIL PROTECTED]> wrote:
> I rebuilt cvsup from net/cvsup yesterday on a new world, and
> it appears to be working fine. What problems should I expect?
It's possible that if you already have a working installation of pm3
or ezm3, you'll be able to b
On Thu, Nov 07, 2002 at 08:40:32AM -0800, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> M. Warner Losh <[EMAIL PROTECTED]> wrote:
> > In message: <[EMAIL PROTECTED]>
> > "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
> > : Could someone add the following patch to UPDATING?
> >
In article <[EMAIL PROTECTED]>,
M. Warner Losh <[EMAIL PROTECTED]> wrote:
> In message: <[EMAIL PROTECTED]>
> "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
> : Could someone add the following patch to UPDATING?
> : Change the words to whatever suits your fancy.
>
> I'm trying to devise
In message: <[EMAIL PROTECTED]>
"Steven G. Kargl" <[EMAIL PROTECTED]> writes:
: M. Warner Losh said:
: > In message: <[EMAIL PROTECTED]>
: > "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
: > : M. Warner Losh said:
: > : > In message: <[EMAIL PROTECTED]>
: > : > "
M. Warner Losh said:
> In message: <[EMAIL PROTECTED]>
> "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
> : M. Warner Losh said:
> : > In message: <[EMAIL PROTECTED]>
> : > "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
> : > : Could someone add the following patch to UPDATING
In message: <[EMAIL PROTECTED]>
"Steven G. Kargl" <[EMAIL PROTECTED]> writes:
: M. Warner Losh said:
: > In message: <[EMAIL PROTECTED]>
: > "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
: > : Could someone add the following patch to UPDATING?
: > : Change the words to whate
M. Warner Losh said:
> In message: <[EMAIL PROTECTED]>
> "Steven G. Kargl" <[EMAIL PROTECTED]> writes:
> : Could someone add the following patch to UPDATING?
> : Change the words to whatever suits your fancy.
>
> I'm trying to devise a good way to deal with this breakage and hope it
>
In message: <[EMAIL PROTECTED]>
"Steven G. Kargl" <[EMAIL PROTECTED]> writes:
: Could someone add the following patch to UPDATING?
: Change the words to whatever suits your fancy.
I'm trying to devise a good way to deal with this breakage and hope it
is transient. I'm not hopeful :-(
Steve Kargl wrote:
> > Any chance we could get rid of all externally visable symbols that
> > are not defined as being there by some standard, and not just __sF,
> > since we are breaking the FORTRAN compiler and other third party
> > code already?
>
> This isn't restricted to my Fortran 95 proble
On Wed, Nov 06, 2002 at 04:38:55PM -0800, Terry Lambert wrote:
> "Steven G. Kargl" wrote:
> > Could someone add the following patch to UPDATING?
> > Change the words to whatever suits your fancy.
> > +20021031
> > + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static.
> > + Th
"Steven G. Kargl" wrote:
> Could someone add the following patch to UPDATING?
> Change the words to whatever suits your fancy.
> +20021031
> + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static.
> + This changes the visibility of __sF to a symbol internal to
> + libc.
60 matches
Mail list logo