* 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 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
On Sat, Nov 02, 2002 at 08:42:57PM -0800, Marcel Moolenaar wrote:
> On Sat, Nov 02, 2002 at 03:58:14PM -0800, Steve Kargl wrote:
> > > >
> > > > See the new WANT_COMPAT4_STDIO make.conf knob.
> > >
> > > This won't be acceptable as the vender will likely not be producing a
> > > separate 5.0 build
On Sat, Nov 02, 2002 at 03:58:14PM -0800, Steve Kargl wrote:
> > >
> > > See the new WANT_COMPAT4_STDIO make.conf knob.
> >
> > This won't be acceptable as the vender will likely not be producing a
> > separate 5.0 build (ie the same build needs to run on both.) until 4.x is
> > EOLed. Forcing pe
In the last episode (Nov 02), Steve Kargl said:
> On Sat, Nov 02, 2002 at 04:19:10PM -0800, Juli Mallett wrote:
> > Keep in mind this only affects linking a closed library, and that
> > this situation is a bit absurd, given that a reasonable solution
> > exists, and if necessary, can be packaged up
On Sat, Nov 02, 2002 at 05:40:08PM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Steve Kargl <[EMAIL PROTECTED]> writes:
> : http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/\
> : www/db/text/2002/freebsd-current/20021013.freebsd-current
>
> You
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 fairly high support
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 needs to see __sF.
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
: > On Sat, 2 Nov 2002, Mark Murray wrote:
: > > This shouldn't be a problem. The commercial software Should Not Be(tm)
: > > supporting something a
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/\
: www/db/text/2002/freebsd-current/20021013.freebsd-current
You should be linking against the -stable versions of these items as
well as th
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 matter that __sF is going to remain
On Sat, Nov 02, 2002 at 04:19:10PM -0800, Juli Mallett wrote:
>
> Keep in mind this only affects linking a closed library, and that this
> situation is a bit absurd, given that a reasonable solution exists, and
> if necessary, can be packaged up nicely...
"A bit absurd"? Can you explain why it i
* 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
On Sat, Nov 02, 2002 at 06:36:31PM -0500, Matthew N. Dodd wrote:
> 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 WAN
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).
Yes. The knob may help you n
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
On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
> On Sat, 2 Nov 2002, Mark Murray wrote:
> > This shouldn't be a problem. The commercial software Should Not Be(tm)
> > supporting something as variable as CURRENT, and with the STABLE libraries
> > around in COMPAT mode, the compiler
On Sat, 2 Nov 2002, Mark Murray wrote:
> This shouldn't be a problem. 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 _
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
> > C file. The C file is compiled by gcc.
>
> > 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 _has_ to be some kind of way to
specify whi
On Sat, Nov 02, 2002 at 12:06:38PM -0800, Peter Wemm wrote:
>
> This is also solveable by setting a strategic symlink from libc.so ->
> /usr/lib/compat/libc.so.4 in the f95 backend's search path.
>
> Does it do a "gcc -o a a.c -L /usr/local/lib/f95 -lf96 -lm -lc" or something
> like that? If so,
On Sat, Nov 02, 2002 at 12:00:42PM -0800, Marcel Moolenaar wrote:
> On Sat, Nov 02, 2002 at 11:24:32AM -0800, Steve Kargl wrote:
> >
> > No, it does not just work. The NAG f95 compiler generates a
> > C file. The C file is compiled by gcc.
> >
> > f95 -o a a.f90
> >
> > is equivalent to
> >
Steve Kargl wrote:
> On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote:
> > > I seriously doubt that NAG will support both a
> > > 4.x and 5.x version of their compiler.
> >
> > This shouldn't be a problem. The commercial software Should Not Be(tm)
> > supporting something as variable a
On Sat, Nov 02, 2002 at 11:24:32AM -0800, Steve Kargl wrote:
> On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote:
> > > I seriously doubt that NAG will support both a
> > > 4.x and 5.x version of their compiler.
> >
> > This shouldn't be a problem. The commercial software Should Not Be(
On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote:
> > I seriously doubt that NAG will support both a
> > 4.x and 5.x version of their compiler.
>
> This shouldn't be a problem. The commercial software Should Not Be(tm)
> supporting something as variable as CURRENT, and with the STABLE
> I seriously doubt that NAG will support both a
> 4.x and 5.x version of their compiler.
This shouldn't be a problem. 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 sh
On Sat, Nov 02, 2002 at 10:58:41AM -0800, Will Andrews wrote:
> On Sat, Nov 02, 2002 at 10:10:31AM -0800, Steve Kargl wrote:
> > This will break some commercially available software that
> > can't easily replaced.
> >
> > kargl[248] f95 -V a.f90
> > NAGWare Fortran 95 compiler Release 4.2(468)
> >
On Sat, Nov 02, 2002 at 10:10:31AM -0800, Steve Kargl wrote:
> This will break some commercially available software that
> can't easily replaced.
>
> kargl[248] f95 -V a.f90
> NAGWare Fortran 95 compiler Release 4.2(468)
> Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K.
> f95
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 commercially available software that
ca
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.
Kris
msg45920/pgp0.pgp
Description: PGP signature
On Sat, 2 Nov 2002, Mark Murray wrote:
> > In both cases, FreeBSD doesn't seem to like __sF.
>
> This is being discussed /ad nauseam/ on the lists. If you are running
> CURRENT, the onus is on you to keep up with developments. :-)
True. A few days after the first time I encountered this pro
> In both cases, FreeBSD doesn't seem to like __sF.
This is being discussed /ad nauseam/ on the lists. If you are running
CURRENT, the onus is on you to keep up with developments. :-)
> Now, the first time this happened, I simply cvsuped a couple days
> later and the problem went away
36 matches
Mail list logo