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
whining about how they shouldn't have been fiddling with
: these symbols in the first place is bound to be a fruitless exercise.
This is why I put __sF back, and made sure that 4.x had the right
'forward compatible' libraries. It is also why I backported the
__std{in,out,err}p sy
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
rovide a pre-built version that doesn't get installed
> > > by default.
> >
> > So what you are saying, basically, is that we should ship a
> > release, for the first time ever, which can't run old binaries.
> > Sorry, that isn't acceptable. The correct an
is that we should ship a release, for
> the first time ever, which can't run old binaries. Sorry, that isn't
> acceptable. The correct and robust way of doing things is to stop
> creating binaries (in both 4.x and 5.x) that reference __sF, then wait
> a full release cycle
or 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
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
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.
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
&g
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
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 t
gt; 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?
The key to this is "on a per object basis".
You only get one .init section, and if y
en <[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
e 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
t; : 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
> ha
"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.
>
&
interdependencies among the libraries and it deals
> | with the version number problems I detailed in the thread
> | "Ghost of __sF ..." a couple a days ago.
> | 3. Put a big fat WARNING in src/UPDATING about the problem
> | 4. Put the same WARNING in /etc/motd,
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
o this, the time
: > > for the pain was 6-9 months ago, not just before the release.
: >
: > 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/bin
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
following 4.7 libs make reference to __sF.
libalias.so.4libbz2.so.1 libc.so.4libc_r.so.4
libcam.so.2 libcom_err.so.2 libcrypto.so.2 libdes.so.3
libdevstat.so.2 libdialog.so.4libedit.so.3 libfetch.so.3
libftpio.so.5libg2c.so.1 libgmp.so.3 libhis
s I detailed in the thread
| "Ghost of __sF ..." a couple a days ago.
| 3. Put a big fat WARNING in src/UPDATING about the problem
| 4. Put the same WARNING in /etc/motd, so people currently
| run -current will know to update their ports.
| 5. Broadcast the WARNING to appr
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).
>
> This is 5.0; it is a major release and
> : > 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
:
amount of
overhead, than to export a data interface.
Note that data interfaces get in the way of the LGPL "relink"
clause for shared libraries. For example, if you had a GPL'ed
program that was written in Modula 3 or FORTRAN 95, that had a
reference to the __sF, then distribution of
> 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
"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)
: >
> 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 peo
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 a
and stderr are defined as above, but they're not any more.
> : Because Modula-3 isn't C and doesn't use C header files, it cannot
> : automatically track such changes like C programs do.
>
> Gotcha. I'm thinking very seriously about keeping __sF support (but
> crea
: >
: > : FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
: > : -current is to make __sF global again and arrange for:
: > :
: > : stdin == &__sF[0]
: > : stdout == &__sF[1]
: > : stderr == &__sF[2]
: >
: > Why does cv
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
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
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
king installation of pm3
> > > or ezm3, you'll be able to build CVSup on -current. But if you try to
> > > build pm3 or ezm3 from scratch, you'll find that the build fails.
> > >
> >
> > I removed all ports because of the __sF symbol problem. I
>
g this to UPDATING.
:
: FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
: -current is to make __sF global again and arrange for:
:
: stdin == &__sF[0]
: stdout == &__sF[1]
: stderr == &__sF[2]
Why does cvsup need this to be the case? Now you have me curi
ent. But if you try to
> > build pm3 or ezm3 from scratch, you'll find that the build fails.
> >
>
> I removed all ports because of the __sF symbol problem. I
> simply did "cd /usr/ports/net/cvsup ; make install" and
> this automatically installed ezm3. pkg
I expect?
>
> 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 or ezm3 from scratch, you'll find that the build fails.
>
I removed all ports because of the __s
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
DATING.
>
> FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
> -current is to make __sF global again and arrange for:
>
> stdin == &__sF[0]
> stdout == &__sF[1]
> stderr == &__sF[2]
>
John,
As the author of cvsup, I'
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 :-( I'll consider adding this to UPDATING.
FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
-current is to make __sF glo
when they update to
: > : post 20021031 sources. All their ports will stop
: > : working and it isn't a simple matter to update
: > : those ports.
: >
: > I thought DP1 didn't generate binaries or libraries that contained
: > __sF.
: >
:
: http://www.freebsd.org/releases/5
onsider adding this to UPDATING.
> : >
> :
> : Any user who installed DP1 and a bunch of ports will
> : have a unpleasant experience when they update to
> : post 20021031 sources. All their ports will stop
> : working and it isn't a simple matter to update
> : those p
ed DP1 and a bunch of ports will
: have a unpleasant experience when they update to
: post 20021031 sources. All their ports will stop
: working and it isn't a simple matter to update
: those ports.
I thought DP1 didn't generate binaries or libraries that contained
__sF.
However, the warnin
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
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/lib
"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 i
disable these features on build machines
to maximize performance.
+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. All applications linked against libc or a library that
* De: Steve Kargl <[EMAIL PROTECTED]> [ Data: 2002-11-03 ]
[ Subjecte: Re: __sF ]
> On Sun, Nov 03, 2002 at 09:28:24AM -0800, Juli Mallett wrote:
> > * De: Steve Kargl <[EMAIL PROTECTED]> [ Data: 2002-11-03 ]
> > [ Subjecte: Re: __sF ]
> > >
In message: <[EMAIL PROTECTED]>
Juli Mallett <[EMAIL PROTECTED]> writes:
: Then you should seriously consider the quality of such application, or
: whether you'd be better using it on an actual and supported platform.
:
: Anything less would be uncivilised. (Seriously)
Sometimes you
On Sun, Nov 03, 2002 at 09:28:24AM -0800, Juli Mallett wrote:
> * De: Steve Kargl <[EMAIL PROTECTED]> [ Data: 2002-11-03 ]
> [ Subjecte: Re: __sF ]
> > As to my particular problem, a cross-platform
> > environment won't be of much use because NAG
> > hard
* De: Steve Kargl <[EMAIL PROTECTED]> [ Data: 2002-11-03 ]
[ Subjecte: Re: __sF ]
> As to my particular problem, a cross-platform
> environment won't be of much use because NAG
> hard-coded several paths into their app, e.g.,
> /usr/bin/cc.
Then you should serious
On Sat, Nov 02, 2002 at 11:05:18PM -0800, Marcel Moolenaar wrote:
> On Sat, Nov 02, 2002 at 09:59:16PM -0800, Steve Kargl wrote:
> >
> > The following libraries are installed by COMPAT4X, but are not
> > present in 4.7. I assume these are carried forward from 4.x x < 7.
> >
> > libssl.so.1
On Sun, Nov 03, 2002 at 03:29:04AM -0800, Juli Mallett wrote:
> * De: Steve Kargl <[EMAIL PROTECTED]> [ Data: 2002-11-02 ]
> [ Subjecte: Re: __sF ]
> > On Sat, Nov 02, 2002 at 05:40:08PM -0700, M. Warner Losh wrote:
> > > In message: <[EMAIL PROTECTED]>
&
* De: Steve Kargl <[EMAIL PROTECTED]> [ Data: 2002-11-02 ]
[ Subjecte: Re: __sF ]
> On Sat, Nov 02, 2002 at 05:40:08PM -0700, M. Warner Losh wrote:
> > In message: <[EMAIL PROTECTED]>
> > Steve Kargl <[EMAIL PROTECTED]> writes:
> > : http
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: The following 4.7 libs make reference to __sF. Several of the
: corresponding 5.0 libraries still have the same version number.
: We may need to bump the version numbers.
:
: libalias.so.4
On Sat, Nov 02, 2002 at 11:25:29PM -0800, Kris Kennaway wrote:
> On Sat, Nov 02, 2002 at 11:05:18PM -0800, Marcel Moolenaar wrote:
> > On Sat, Nov 02, 2002 at 09:59:16PM -0800, Steve Kargl wrote:
> > >
> > > The following libraries are installed by COMPAT4X, but are not
> > > present in 4.7. I as
On Sat, Nov 02, 2002 at 11:05:18PM -0800, Marcel Moolenaar wrote:
> On Sat, Nov 02, 2002 at 09:59:16PM -0800, Steve Kargl wrote:
> >
> > The following libraries are installed by COMPAT4X, but are not
> > present in 4.7. I assume these are carried forward from 4.x x < 7.
> >
> > libssl.so.1
This means we had version bumps on -stable without
providing compat4x libraries on 4.x - I think we're seriously
fscking up here :-(
> The following 4.7 libs make reference to __sF. Several of the
> corresponding 5.0 libraries still have the same version number.
> We may
Since I appear to one the few people caught by the __sF and commercial
software broken by staticizing __sF, I decided to look at the 4.7
live filesystem ISO image to see what I would need to build a proper
set of libraries. Here is a summary of what I found.
List of shared libraries in 4.7 not
> > who wants to runs this vendor's 4.x software, will need to
> > build their libc with WANT_COMPAT4_STDIO defined if this
> > product needs to see __sF.
>
> No; you're mixing things up. The compat4x stuff we have now allows
> you to run 4.x binaries on 5.x.
n both.) until 4.x is
> > EOLed. Forcing people to rebuild libc seems a high barrier to entry.
> >
>
> Maybe I misunderstand you. But, a person running FreeBSD 5.x,
> who wants to runs this vendor's 4.x software, will need to
> build their libc with WANT_COMPAT4_STDIO
l develop where the tools are
> > working and supported (keep in mind this is a issue with a vendor
> > LIBRARY being LINKED in, not a TOOL being USED),
>
> The TOOL was working fine until __sF was made static.
It may work fine for 5.0. There's no guarantee that later on
ot binary
> compatible with .4, and for more reasons than just __sF.
>
Fine, I'll try to set up a cross build enviroment.
But, we need to then install a complete set of 4.x
libraries in /usr/lib/compat.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sat, 2 Nov 2002, Steve Kargl wrote:
> Maybe I misunderstand you. But, a person running FreeBSD 5.x,
> who wants to runs this vendor's 4.x software, will need to
> build their libc with WANT_COMPAT4_STDIO defined if this
> product needs to see __sF.
Yes, and this presents a fa
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: Maybe I misunderstand you. But, a person running FreeBSD 5.x,
: who wants to runs this vendor's 4.x software, will need to
: build their libc with WANT_COMPAT4_STDIO defined if this
: product
: > > supporting something as variable as CURRENT, and with the STABLE libraries
: > > around in COMPAT mode, the compiler Will Just Work(tm) (or should with
: > > not much effort).
: > >
: > > By the time __sF is mainstream, I guess the vendor will have adapted
: >
s as
well as the libc.so.4. If you don't, then you are asking for
problems. Maybe you can kludge it to make libc.so.5 work, but the
whole reason that it is .5 and not .4 is that it is not binary
compatible with .4, and for more reasons than just __sF.
Warner
To Unsubscribe: send mail to [EMAI
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: On Sat, Nov 02, 2002 at 09:47:26AM -0800, Kris Kennaway wrote:
: > On Sat, Nov 02, 2002 at 10:35:03AM -0500, Adam K Kirchhoff wrote:
: >
: > > So is the current position on the matt
a vendor LIBRARY being
> LINKED in, not a TOOL being USED),
The TOOL was working fine until __sF was made static.
> or set up a proper cross-env to target the platform where the library
> is targettted
This is what I guess we'll have to do.
> or will force their vendor to supp
* De: "Matthew N. Dodd" <[EMAIL PROTECTED]> [ Data: 2002-11-02 ]
[ Subjecte: Re: __sF ]
> On Sat, 2 Nov 2002, Steve Kargl wrote:
> > On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
> > > This isn't the case for one piece of vendor
ms a high barrier to entry.
>
Maybe I misunderstand you. But, a person running FreeBSD 5.x,
who wants to runs this vendor's 4.x software, will need to
build their libc with WANT_COMPAT4_STDIO defined if this
product needs to see __sF.
This is my exact problem. I have NAG's Fortran 9
On Sat, Nov 02, 2002 at 12:22:38PM -0800, Steve Kargl wrote:
>
> The verbose compiler output is below. Note,
> that the crt* files are also 5.x instead of
> 4.x. Maybe it's just good fortune, but NAG's
> f95 compiler works great on 5.x (except for
> the __sF snafu).
On Sat, 2 Nov 2002, Steve Kargl wrote:
> On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
> > This isn't the case for one piece of vendor software that I'm not allowed
> > to talk about.
>
> See the new WANT_COMPAT4_STDIO make.conf knob.
This won't be acceptable as the vender will
around in COMPAT mode, the compiler Will Just Work(tm) (or should with
> > not much effort).
> >
> > By the time __sF is mainstream, I guess the vendor will have adapted
> > their product to match. Win, win.
>
> This isn't the case for one piece of vendor s
.
>
> By the time __sF is mainstream, I guess the vendor will have adapted
> their product to match. Win, win.
This isn't the case for one piece of vendor software that I'm not allowed
to talk about.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD
On Sat, Nov 02, 2002 at 08:42:35PM +, Mark Murray wrote:
> > > By the time __sF is mainstream, I guess the vendor will have adapted
> > > their product to match. Win, win.
> > >
> >
> > No, it does not just work. The NAG f95 compiler generates a
>
> > By the time __sF is mainstream, I guess the vendor will have adapted
> > their product to match. Win, win.
> >
>
> No, it does not just work. The NAG f95 compiler generates a
> C file. The C file is compiled by gcc.
How about "much effort"? there _h
or something
> like that? If so, you can put the libc.so symlink in there.
>
> I assume that the generated code doesn't contain #includes... If it does
> you'll also need to do something about that so that you get the right
> #includes. libf96.so is a 4.x binary. Even
ick up the
> 4.x headers and libraries by having an alternate system includes
> and libraries path. With GCC this should be simple enough.
>
That's exactly the problem. I haven't been able to
state it in the same manner as you.
Alfred just committed a make.conf knob, W
)
> > supporting something as variable as CURRENT, and with the STABLE libraries
> > around in COMPAT mode, the compiler Will Just Work(tm) (or should with
> > not much effort).
> >
> > By the time __sF is mainstream, I guess the vendor will have adapted
> > their
The commercial software Should Not Be(tm)
> > supporting something as variable as CURRENT, and with the STABLE libraries
> > around in COMPAT mode, the compiler Will Just Work(tm) (or should with
> > not much effort).
> >
> > By the time __sF is mainstream, I gue
RRENT, and with the STABLE libraries
> around in COMPAT mode, the compiler Will Just Work(tm) (or should with
> not much effort).
>
> By the time __sF is mainstream, I guess the vendor will have adapted
> their product to match. Win, win.
>
No, it does not just work. The NAG
ork(tm) (or should with
not much effort).
By the time __sF is mainstream, I guess the vendor will have adapted
their product to match. Win, win.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curr
re Fortran 95 compiler Release 4.2(468)
> > Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K.
> > f95comp version is 4.2(468)
> > /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF'
> > collect2: ld returned 1 exit status
> >
>
Group Ltd., Oxford, U.K.
> f95comp version is 4.2(468)
> /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF'
> collect2: ld returned 1 exit status
>
> I seriously doubt that NAG will support both a
> 4.x and 5.x version of their compiler.
That's why we have c
On Sat, Nov 02, 2002 at 09:47:26AM -0800, Kris Kennaway wrote:
> On Sat, Nov 02, 2002 at 10:35:03AM -0500, Adam K Kirchhoff wrote:
>
> > So is the current position on the matter that __sF is going to remain out
> > of libc?
>
> Yes.
>
This will break some commercia
1 - 100 of 174 matches
Mail list logo
