Re: __sF
* 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://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 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. 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. No, that's for runtime compatability. You want a true cross environment. Read any of the thousands of pages about setting up GCC for cross-platform development, as that's what you're doing. You just happen to have a chance of running the cross-created things locally. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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] You should be linking against the -stable versions of these items 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. 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. No, that's for runtime compatability. You want a true cross environment. Read any of the thousands of pages about setting up GCC for cross-platform development, as that's what you're doing. You just happen to have a chance of running the cross-created things locally. Let's say I have an 4.7 app linked against libcam.so. Now, I update to 5.0. What library will this app use? There isn't a COMPAT4X library available and the 5.0 has the same version number and libcam.so has a reference to __sF. There probably aren't many apps that use libcam, so this is perhaps stretch. Well, consider libm.so and the 8000 ports. 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. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
* 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 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) -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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 ] 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 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) This is the *only* native Fortran 95 compiler for FreeBSD. So much for acceptance of FreeBSD by commerical vendors. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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 have no chocie in what you accept or not. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
* 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 ] 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 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) This is the *only* native Fortran 95 compiler for FreeBSD. ^ 4.x -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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, but now it's back, which is making me think I never really solved the problem the first time around. Any ideas on how to permanently fix this problem? Rebuild _everything_. Ports, libraries, dependancies, the lot. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 problem, I had searched through the archives and seen a very recent discussion about how it was fixed it -CURRENT about two days after I had upgraded. So I upgraded again and, indeed, the problem was fixed. And this past time, though, I did check out the archives again... I came across this post: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1438233+1440468+/usr/local/www/db/text/2002/freebsd-current/20021020.freebsd-current It indicated that __sF was added back into libc. Now, the first time this happened, I simply cvsuped a couple days later and the problem went away, but now it's back, which is making me think I never really solved the problem the first time around. Any ideas on how to permanently fix this problem? Rebuild _everything_. Ports, libraries, dependancies, the lot. So is the current position on the matter that __sF is going to remain out of libc? If that's the case, fine, I have no objections to recompiling all my ports, but the fact of the matter is that there doesn't seem to be much agreement about whether or not that's the case, seeing how __sF keeps getting removed and re-added. Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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
Re: __sF
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 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. 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. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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. 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 compat libs. compat4x should handle this unless I'm mistaken. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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) 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 I seriously doubt that NAG will support both a 4.x and 5.x version of their compiler. That's why we have compat libs. compat4x should handle this unless I'm mistaken. It doesn't work the way you think. To understand the issues http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/\ www/db/text/2002/freebsd-current/20021013.freebsd-current -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 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-current in the body of the message
Re: __sF
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 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 f95 compiler generates a C file. The C file is compiled by gcc. f95 -o a a.f90 is equivalent to f95 -c -o a.c a.f90 gcc -o a a.c -lf96 -lm -lc libf96.so is linked against libc.so, which is a symlink to libc.so.4 on a 4.x system. libm.so and libc.so are symlinks that point to libm.so.2 and libc.so.5 on 5.x. You pick up the wrong libc.so in the above line. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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(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 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. f95 -o a a.f90 is equivalent to f95 -c -o a.c a.f90 gcc -o a a.c -lf96 -lm -lc libf96.so is linked against libc.so, which is a symlink to libc.so.4 on a 4.x system. libm.so and libc.so are symlinks that point to libm.so.2 and libc.so.5 on 5.x. You pick up the wrong libc.so in the above line. I see where this is breaking. The compat libs work because binaries are already linked against them. What you're describing is a need to link against libc.so.4 whilst on a -current box. Much the same as developing under the Linuxulator: you're not using the native bits. The problem is not unsolvable, but you also need the 4.x headers to make it work. The first hurdle is getting NAG f90 to pick up a random C compiler. The random C compiler then has to pick up the 4.x headers and libraries by having an alternate system includes and libraries path. With GCC this should be simple enough. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 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 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. f95 -o a a.f90 is equivalent to f95 -c -o a.c a.f90 gcc -o a a.c -lf96 -lm -lc libf96.so is linked against libc.so, which is a symlink to libc.so.4 on a 4.x system. libm.so and libc.so are symlinks that point to libm.so.2 and libc.so.5 on 5.x. You pick up the wrong libc.so in the above line. 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, 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 if it wasn't for __sF, you should be compiling with 4.x libraries and (if needed) 4.x headers, because you have parts of the 4.x stdio.h embedded in libf96.so. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 f95 -c -o a.c a.f90 gcc -o a a.c -lf96 -lm -lc libf96.so is linked against libc.so, which is a symlink to libc.so.4 on a 4.x system. libm.so and libc.so are symlinks that point to libm.so.2 and libc.so.5 on 5.x. You pick up the wrong libc.so in the above line. I see where this is breaking. The compat libs work because binaries are already linked against them. What you're describing is a need to link against libc.so.4 whilst on a -current box. Much the same as developing under the Linuxulator: you're not using the native bits. The problem is not unsolvable, but you also need the 4.x headers to make it work. The first hurdle is getting NAG f90 to pick up a random C compiler. The random C compiler then has to pick 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, WANT_COMPAT4_STDIO, that permits libc to be built with __sF visible outside of libc. I suspect most people will not need the knob, but it will allow commercial apps to run if need be. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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, 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 if it wasn't for __sF, you should be compiling with 4.x libraries and (if needed) 4.x headers, because you have parts of the 4.x stdio.h embedded in libf96.so. The only include that I any aware of is f95.h which mainly defines stuff in libf95 (e.g., a typedef for struct nagf95_complex). 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). -- Steve kargl[226] f95 -v -Wc,-v -Wl,-v a.f90 a.f90: Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) /usr/libexec/cc1 -lang-c -v -I/usr/local/lib/NAGWare -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -Dunix -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -D__unix__ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__ELF__ -D_LONGLONG -DBSD -DANSI_C -DINT64=long long -DPOW_IS_INACCURATE /var/tmp/a.051193.c -quiet -dumpbase a.051193.c -version -fsigned-char -o /var/tmp/cczLSErX.s GNU CPP version 3.2.1 [FreeBSD] 20021009 (prerelease) (cpplib) (i386 FreeBSD/ELF) GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease) (i386-undermydesk-freebsd) compiled by GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease). ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/local/lib/NAGWare /usr/include End of search list. /usr/bin/as -v -o a.o /var/tmp/cczLSErX.s GNU assembler version 2.13 [FreeBSD] 2002-10-10 (i386-obrien-freebsd5.0) using BFD version 2.13 [FreeBSD] 2002-10-10 Loading... Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) /usr/libexec/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /usr/local/lib/NAGWare/quickfit.o a.o -rpath /usr/local/lib/NAGWare /usr/local/lib/NAGWare/libf96.so /usr/local/lib/NAGWare/libf96.a -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o GNU ld version 2.13 [FreeBSD] 2002-10-10 Supported emulations: elf_i386_fbsd To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 which C library to use. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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. How about much effort? there _has_ to be some kind of way to specify which C library to use. The only work-around I know is documented in (watch the line wrap) http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/www\ /db/text/2002/freebsd-current/20021013.freebsd-current To recap, I can do f95 -c hello.f90 gcc -v -o hello -nostdlib \ /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o \ /usr/local/lib/NAGWare/quickfit.o hello.o /usr/local/lib/NAGWare/libf96.so\ -lm \ /usr/home/karg/tmp/minpack/lib/libc.so \ /usr/lib/crtend.o /usr/lib/crtn.o But, the 2nd and 6th lines in the gcc command use the crt* files from freebsd-current. The math library, -lm, is also from freebsd-current. /usr/lib/compat does contains neither a 4.x math library nor the crt* files. The libc.so in the above is a symlink kargl[274] ldd hello hello: libf96.so.1 = /usr/local/lib/NAGWare/libf96.so.1 (0x2806b000) libm.so.2 = /usr/lib/libm.so.2 (0x2810b000) libc.so.4 = /usr/lib/compat/libc.so.4 (0x28129000) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 __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/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 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 software that I'm not allowed to talk about. See the new WANT_COMPAT4_STDIO make.conf knob. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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 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 likely not be producing a separate 5.0 build (ie the same build needs to run on both.) until 4.x is EOLed. Forcing people to rebuild libc seems a high barrier to entry. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 now, but there's no guarantee that you'll get hosed later on. Probably the easiest *real* solution would be to build gcc on a 4.x machine and have it installed under /usr/local. It will have a FQ name like i386-unknown-freebsd4.0-gcc. That version has default paths for both includes and libraries in the gcc tree rooted under /usr/local. You can populate that tree with headers and libraries found on 4.x machine and then move it over (or NFS export it) to your 5.x box. In short: you've set yourself up for crossbuilding... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 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 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 defined if this product needs to see __sF. This is my exact problem. I have NAG's Fortran 95 compiler, which was built for FreeBSD 4.2. I ran it on 5.0 without a problem until __sF was made static. NAG may never release a 5.x version of their compiler because it may not be cost effective. This is a compromise to move forward with the elimination of the visibility of __sF. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
* 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 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 likely not be producing a separate 5.0 build (ie the same build needs to run on both.) until 4.x is EOLed. Forcing people to rebuild libc seems a high barrier to entry. Not making a clean break by default (i.e. not requiring a rebuild to get the backwards behaviour) causes this to cascade. But it worked in 4.x = Well then by golly it will in 5.0! But it works in 5.0 = Then we'll keep it around for 5.x But it worked in 5.x! = We'll make it tunable (on), but have rtld whine! But it worked in 6.0, despite that rtld bug! etc. Look how long it took Microsoft to deprecate MS DOS apps. It took until they switched to an entirely new kernel (for the product line) and rebadged the hell out of it. I much prefer the idea of move onward, provide a backward solution if someone really needs it... Would it satisfy you to see a port, h0h0libc? Solutions like that can't be guaranteed to work for (N+X).0 systems, to provide vendor _libraries_ to link in a non-cross environment, where N is the system the libraries are for, and where X is some number greater than one. 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... Developers using this sort of environment are asking for trouble. It seems to me a serious developer will 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), or set up a proper cross-env to target the platform where the library is targettted, or will force their vendor to support the new platform they (for whatever reason) see fit to develop on. [ I promise the rest of this won't be something someone will try to construe as a bikeshed. ] juli. -- Juli Mallett [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 is absurb and can you give me the reasonable solution that you have? Developers using this sort of environment are asking for trouble. It seems to me a serious developer will 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. 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 support the new platform they (for whatever reason) see fit to develop on. Force the vendor to support the new platform? No, this will most likely cause the vendor to abandon the FreeBSD platform. So much for encouraging commercial support for FreeBSD. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 out : of libc? : : Yes. : : : 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. : 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. Then you should force it to link with libc.so.4. That's the version of libc that it build libf96.so against, so you are taking a big chance having it use libc.so.5. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __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 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 product to match. Win, win. : : 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. But that knob is a total kludge and *WRONG* for this case. It lets things link, but you are still cross threading 4.x and 5.x binaries, which is asking to be shot in the foot. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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. All that kludge does is to allow a program that shouldn't be allowed to link to link. You need to setup to compile 4.x binaries on the 5.x machine, or you will lose in the long run. __sF is only the first of many issues, some subtle, that you'll face cross-threading 4.x and 5.x libraries. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 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 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. The problem that WANT_COMPAT4_STDIO addresses is *compiling* 4.x compatible programs on 5.x! A world of difference. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __sF
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 (ie the same build needs to run on 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 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. The problem that WANT_COMPAT4_STDIO addresses is *compiling* 4.x compatible programs on 5.x! A world of difference. I just looked through /usr/lib on the 4.7 live ISO. We are missing a bunch of libraries. See another post with the list. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
