Re: __fpclassifyd problem
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. Warner This was already resolved. Java does a dlopen() on /usr/lib/libc.so. Rumor has it that this is fixed. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Thu, Oct 30, 2003 at 11:48:13PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. This was understood already (java is doing a dlopen of /usr/lib/libc.so). Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
Scott Long wrote: M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. Warner This was already resolved. Java does a dlopen() on /usr/lib/libc.so. Rumor has it that this is fixed. Scott But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Fri, Oct 31, 2003, John Angelmo wrote: But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Sounds like you might have accidentally imported e_scalbf.c twice---once as e_scalbf.c and once as e_scalb.c. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Fri, Oct 31, 2003 at 05:55:46PM +0100, John Angelmo wrote: This was already resolved. Java does a dlopen() on /usr/lib/libc.so. Rumor has it that this is fixed. Scott But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Apart from your libm problem (which I didn't see when I did this locally), the fix to the java ports are not yet committed. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
David Schultz wrote: On Fri, Oct 31, 2003, John Angelmo wrote: But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Sounds like you might have accidentally imported e_scalbf.c twice---once as e_scalbf.c and once as e_scalb.c. I used this: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/msun/src/e_scalb.c?rev=1.10content-type=text/plainonly_with_tag=HEAD and this: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/msun/src/e_scalbf.c?rev=1.8content-type=text/plainonly_with_tag=HEAD for the diffrent files, and I checked/tested multiple times now, the files are imported correcty (simple copy paste) I'm using 5.1-p10 and get that error /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
On Wed, 29 Oct 2003, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. [junior] ~ cd /usr/local/diablo-jdk1.3.1/bin [junior] /usr/local/diablo-jdk1.3.1/bin sudo ./java Bus error (core dumped) [junior] /usr/local/diablo-jdk1.3.1/bin sudo gdb ../jre/bin/i386/green_threads/java -core=java.core GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (no debugging symbols found)... Core was generated by `java'. Program terminated with signal 10, Bus error. Reading symbols from ../jre/lib/i386/green_threads/libhpi.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/green_threads/libhpi.so Reading symbols from /usr/lib/compat/libc.so.4... (no debugging symbols found)...done. Loaded symbols for /usr/lib/compat/libc.so.4 Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.2 Reading symbols from /usr/lib/libc.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so Reading symbols from ../jre/lib/i386/classic/libjvm.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/classic/libjvm.so Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 (gdb) bt #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 #1 0x28088a51 in open () from ../jre/lib/i386/green_threads/libhpi.so #2 0x2810033c in __hash_open () from /usr/lib/compat/libc.so.4 #3 0x281001fb in dbopen () from /usr/lib/compat/libc.so.4 #4 0x280c3277 in ttyname () from /usr/lib/compat/libc.so.4 #5 0x280881f0 in initializeTTY () from ../jre/lib/i386/green_threads/libhpi.so #6 0x28088529 in InitializeAsyncIO () from ../jre/lib/i386/green_threads/libhpi.so #7 0x28091ca8 in sysThreadBootstrap () from ../jre/lib/i386/green_threads/libhpi.so #8 0x28295f07 in InitializeJavaVM () from ../jre/lib/i386/classic/libjvm.so #9 0x2826b3e4 in JNI_CreateJavaVM () from ../jre/lib/i386/classic/libjvm.so #10 0x08049c4a in InitializeJVM () #11 0x08048f5e in main () #12 0x08048b65 in _start () (gdb) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Kris Kennaway wrote: On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris I get this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. The binary is linked to: /usr/lib/libm.so.2 /usr/lib/compat/libc.so.4 (and others) (recall: the source of the libm problems was that libc.so.5 was *not* linked in). I'm not sure why gdb says otherwise - perhaps it's confused about the library paths. Perhaps there's some kind of ABI problem here that java is choking on. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
On Wed, 29 Oct 2003, Scott Long wrote: On Wed, 29 Oct 2003, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris To respond to myself, I got ahold of a 4.8 libm.so and made sure that the linker used it. No change in the problem, and it still hints that the native libc is being linked in. Scott I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. [junior] ~ cd /usr/local/diablo-jdk1.3.1/bin [junior] /usr/local/diablo-jdk1.3.1/bin sudo ./java Bus error (core dumped) [junior] /usr/local/diablo-jdk1.3.1/bin sudo gdb ../jre/bin/i386/green_threads/java -core=java.core GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (no debugging symbols found)... Core was generated by `java'. Program terminated with signal 10, Bus error. Reading symbols from ../jre/lib/i386/green_threads/libhpi.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/green_threads/libhpi.so Reading symbols from /usr/lib/compat/libc.so.4... (no debugging symbols found)...done. Loaded symbols for /usr/lib/compat/libc.so.4 Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.2 Reading symbols from /usr/lib/libc.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so Reading symbols from ../jre/lib/i386/classic/libjvm.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/classic/libjvm.so Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 (gdb) bt #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 #1 0x28088a51 in open () from ../jre/lib/i386/green_threads/libhpi.so #2 0x2810033c in __hash_open () from /usr/lib/compat/libc.so.4 #3 0x281001fb in dbopen () from /usr/lib/compat/libc.so.4 #4 0x280c3277 in ttyname () from /usr/lib/compat/libc.so.4 #5 0x280881f0 in initializeTTY () from ../jre/lib/i386/green_threads/libhpi.so #6 0x28088529 in InitializeAsyncIO () from ../jre/lib/i386/green_threads/libhpi.so #7 0x28091ca8 in sysThreadBootstrap () from ../jre/lib/i386/green_threads/libhpi.so #8 0x28295f07 in InitializeJavaVM () from ../jre/lib/i386/classic/libjvm.so #9 0x2826b3e4 in JNI_CreateJavaVM () from ../jre/lib/i386/classic/libjvm.so #10 0x08049c4a in InitializeJVM () #11 0x08048f5e in main () #12 0x08048b65 in _start () (gdb) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
java binary incompatibility on 5.x (Re: __fpclassifyd problem)
On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? Kris pgp0.pgp Description: PGP signature
Re: java binary incompatibility on 5.x (Re: __fpclassifyd problem)
Kris Kennaway wrote: On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? Kris Thanks for tracking this down. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: java binary incompatibility on 5.x (Re: __fpclassifyd problem)
On Wed, Oct 29, 2003 at 06:07:11PM -0800, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? I think its already fixed in CVS. I'll try and test it tomorrow. Does anyone know if ref5 has been updated to after the libm fix? I don't have a -CURRENT box at home to test on. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: java binary incompatibility on 5.x (Re: __fpclassifyd problem)
On Wed, Oct 29, 2003 at 10:40:29PM -0700, Greg Lewis wrote: On Wed, Oct 29, 2003 at 06:07:11PM -0800, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? I think its already fixed in CVS. I'll try and test it tomorrow. Does anyone know if ref5 has been updated to after the libm fix? I don't have a -CURRENT box at home to test on. You should be able to roll your own libm and use LD_LIBRARY_PATH. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. This problem illustrates that we need to be careful as we roll forward support for C99 features that cannot be implemented as regular functions, but that are regular functions in C89. I expect that once all that support is in the tree, we can do a single libm version number bump and remove the compatibility hacks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
[ add compatability hacks to libm ] We tried this at usenix, but it still didn't work. Obviously there is more going on. Before anybody goes and bumps libraries etc, it would be useful to know if running a statically linked jvm will work on -current. This sounds like a good plan, though it should be noted that statically linking the jvm executable will reder it useless since it won't be able to dl_open any of the essential JNI modules. Not just the JNI modules, but basically *all* the modules are dl_opened, so a staticially linked modern JVM can't realistically be created. The last time we were able to create a static JVM was JDK1.1. I spent many weeks attempting to create one for 1.2, and finally gave up. Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Daniel Eischen wrote: On Mon, 20 Oct 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : We need to resolve this before 5.2 in some fashion. It looks like the : easiest thing to do is bump libm. Is this advisable? The problem with bumping libm is that we also need, strictly speaking, to bump all libarires that depend on libm, and that can be very ugly. This moves the bump the major version from the trivial fix class to something that we have to think real hard about. In general one cannot bump the major version of 'base' libaries like this w/o careful thought and planning. While we've done that in the past with libc, I think we were wrong to do so in some classes of symbol tampering. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] If it's just __fpclassifyd(), can you just add a compatability hack to libm so it works with both libc 4.0 and 5.x? You can make __fpclassifyd a weak definition to the hack in libm. I suppose you could also add __fpclassfyd() to libc 4.0. We tried this at usenix, but it still didn't work. Obviously there is more going on. Before anybody goes and bumps libraries etc, it would be useful to know if running a statically linked jvm will work on -current. If that does, then the next thing to try is using a complete exclusive set of 4.x libraries and ld-elf.so.1 somewhere and running in a chroot environment. The next step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and find the 4.x libraries in preference to the 5.x ones. And so on. If it still works at this point, then try switching the unbumped libraries one at a time until it breaks. Bumping the library versions is only useful IF it actually solves the problem. 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Peter Wemm wrote: Daniel Eischen wrote: On Mon, 20 Oct 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : We need to resolve this before 5.2 in some fashion. It looks like the : easiest thing to do is bump libm. Is this advisable? The problem with bumping libm is that we also need, strictly speaking, to bump all libarires that depend on libm, and that can be very ugly. This moves the bump the major version from the trivial fix class to something that we have to think real hard about. In general one cannot bump the major version of 'base' libaries like this w/o careful thought and planning. While we've done that in the past with libc, I think we were wrong to do so in some classes of symbol tampering. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] If it's just __fpclassifyd(), can you just add a compatability hack to libm so it works with both libc 4.0 and 5.x? You can make __fpclassifyd a weak definition to the hack in libm. I suppose you could also add __fpclassfyd() to libc 4.0. We tried this at usenix, but it still didn't work. Obviously there is more going on. Before anybody goes and bumps libraries etc, it would be useful to know if running a statically linked jvm will work on -current. If that does, then the next thing to try is using a complete exclusive set of 4.x libraries and ld-elf.so.1 somewhere and running in a chroot environment. The next step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and find the 4.x libraries in preference to the 5.x ones. And so on. If it still works at this point, then try switching the unbumped libraries one at a time until it breaks. Bumping the library versions is only useful IF it actually solves the problem. This sounds like a good plan, though it should be noted that statically linking the jvm executable will reder it useless since it won't be able to dl_open any of the essential JNI modules. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Wed, 22 Oct 2003, Peter Wemm wrote: Daniel Eischen wrote: If it's just __fpclassifyd(), can you just add a compatability hack to libm so it works with both libc 4.0 and 5.x? You can make __fpclassifyd a weak definition to the hack in libm. I suppose you could also add __fpclassfyd() to libc 4.0. We tried this at usenix, but it still didn't work. Obviously there is more going on. I guess so. That's weird because it seems like it should work. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Steve Kargl wrote: On Sun, Oct 19, 2003 at 03:48:58PM -0700, Kris Kennaway wrote: On Sun, Oct 19, 2003 at 03:13:41PM -0700, Steve Kargl wrote: I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. You don't want to do it before you have to, because this creates more pain for people when you make a change that breaks backwards compat (given the policy/preference of only bumping once per major release). I'm working on a script that will detect the kind of backwards compatibility breakage we're seeing here by comparing the symbols in 4.x and 5.x versions of libraries with the same major revision. We can then run this once a day/week/whatever somewhere to catch these problems as soon as they occur in future. You and I participated in the first go around in the library versioning problem. For one of my attempts to discuss this problem, see http://www.freebsd.org/cgi/getmsg.cgi?fetch=1981830+1986079+/usr/local/www/db/text/2002/freebsd-current/20021103.freebsd-current Are there any hints how to solve my problem, I'm willing to give it a shot ;) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Mon, Oct 20, 2003 at 10:51:50AM +0200, John Angelmo wrote: Are there any hints how to solve my problem, I'm willing to give it a shot ;) We're discussing it, please be patient. kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : We need to resolve this before 5.2 in some fashion. It looks like the : easiest thing to do is bump libm. Is this advisable? The problem with bumping libm is that we also need, strictly speaking, to bump all libarires that depend on libm, and that can be very ugly. This moves the bump the major version from the trivial fix class to something that we have to think real hard about. In general one cannot bump the major version of 'base' libaries like this w/o careful thought and planning. While we've done that in the past with libc, I think we were wrong to do so in some classes of symbol tampering. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
In message: [EMAIL PROTECTED] Steve Kargl [EMAIL PROTECTED] writes: : I sent in an email *along time ago* about this type : of problem. See the fallout due to revision 1.24 : of lib/libc/stdio/findfp.c. IMHO, all shared libraries : versions should have been bumped in going from 4.x to : 5.0. I tend to agree due to some weirdness that forced the libc bump. However, this would then have to includ all ports libraries too. Bumping all ports libraries and having a viable ports system that built on both 4.x and 5.x would then become nightmarish because you'd not want to bump them on 4.x. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Mon, 20 Oct 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : We need to resolve this before 5.2 in some fashion. It looks like the : easiest thing to do is bump libm. Is this advisable? The problem with bumping libm is that we also need, strictly speaking, to bump all libarires that depend on libm, and that can be very ugly. This moves the bump the major version from the trivial fix class to something that we have to think real hard about. In general one cannot bump the major version of 'base' libaries like this w/o careful thought and planning. While we've done that in the past with libc, I think we were wrong to do so in some classes of symbol tampering. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] If it's just __fpclassifyd(), can you just add a compatability hack to libm so it works with both libc 4.0 and 5.x? You can make __fpclassifyd a weak definition to the hack in libm. I suppose you could also add __fpclassfyd() to libc 4.0. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
__fpclassifyd problem
Hello I'm trying to install java-checkstyle on my 5.1 system, the system is upto date (p10) but I get this build error: ===[root] /usr/ports/java/java-checkstyle # make === Extracting for java-checkstyle-3.1 Checksum OK for checkstyle-src-3.1.tar.gz. === Patching for java-checkstyle-3.1 === java-checkstyle-3.1 depends on file: /usr/local/bin/ant - found === java-checkstyle-3.1 depends on file: /usr/local/diablo-jdk1.3.1/bin/java - found === Configuring for java-checkstyle-3.1 === Building for java-checkstyle-3.1 /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __fpclassifyd *** Error code 1 Stop in /usr/ports/java/java-checkstyle. What I understand is that the problem is that I can have some stale libs in /usr/lib how can I solve this? /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Sun, Oct 19, 2003 at 09:08:25PM +0200, John Angelmo wrote: Hello I'm trying to install java-checkstyle on my 5.1 system, the system is upto date (p10) but I get this build error: ===[root] /usr/ports/java/java-checkstyle # make === Extracting for java-checkstyle-3.1 Checksum OK for checkstyle-src-3.1.tar.gz. === Patching for java-checkstyle-3.1 === java-checkstyle-3.1 depends on file: /usr/local/bin/ant - found === java-checkstyle-3.1 depends on file: /usr/local/diablo-jdk1.3.1/bin/java - found === Configuring for java-checkstyle-3.1 === Building for java-checkstyle-3.1 /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __fpclassifyd *** Error code 1 Stop in /usr/ports/java/java-checkstyle. What I understand is that the problem is that I can have some stale libs in /usr/lib how can I solve this? This symbol is defined in libc.so.5. One way you can see this problem is if you are running a 4.x binary that links to libm.so.2 on a 5.x system, because libm has the same version number in 5.x but is not binary compatible. So the 4.x binary links to libc.so.4 and libm.so.2, and the latter is actually a 5.x library that expects to have __fpclassifyd resolved by linking with libc.so.5. Is it the case on your system that you have old 4.x binaries installed? Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
Kris Kennaway wrote: On Sun, Oct 19, 2003 at 09:08:25PM +0200, John Angelmo wrote: Hello I'm trying to install java-checkstyle on my 5.1 system, the system is upto date (p10) but I get this build error: ===[root] /usr/ports/java/java-checkstyle # make === Extracting for java-checkstyle-3.1 Checksum OK for checkstyle-src-3.1.tar.gz. === Patching for java-checkstyle-3.1 === java-checkstyle-3.1 depends on file: /usr/local/bin/ant - found === java-checkstyle-3.1 depends on file: /usr/local/diablo-jdk1.3.1/bin/java - found === Configuring for java-checkstyle-3.1 === Building for java-checkstyle-3.1 /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __fpclassifyd *** Error code 1 Stop in /usr/ports/java/java-checkstyle. What I understand is that the problem is that I can have some stale libs in /usr/lib how can I solve this? This symbol is defined in libc.so.5. One way you can see this problem is if you are running a 4.x binary that links to libm.so.2 on a 5.x system, because libm has the same version number in 5.x but is not binary compatible. So the 4.x binary links to libc.so.4 and libm.so.2, and the latter is actually a 5.x library that expects to have __fpclassifyd resolved by linking with libc.so.5. Is it the case on your system that you have old 4.x binaries installed? Yes I upgraded from 4.8 to 5.1 I now have compat4 installed to /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Kris Kennaway wrote: On Sun, Oct 19, 2003 at 09:08:25PM +0200, John Angelmo wrote: Hello I'm trying to install java-checkstyle on my 5.1 system, the system is upto date (p10) but I get this build error: ===[root] /usr/ports/java/java-checkstyle # make === Extracting for java-checkstyle-3.1 Checksum OK for checkstyle-src-3.1.tar.gz. === Patching for java-checkstyle-3.1 === java-checkstyle-3.1 depends on file: /usr/local/bin/ant - found === java-checkstyle-3.1 depends on file: /usr/local/diablo-jdk1.3.1/bin/java - found === Configuring for java-checkstyle-3.1 === Building for java-checkstyle-3.1 /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __fpclassifyd *** Error code 1 Stop in /usr/ports/java/java-checkstyle. What I understand is that the problem is that I can have some stale libs in /usr/lib how can I solve this? This symbol is defined in libc.so.5. One way you can see this problem is if you are running a 4.x binary that links to libm.so.2 on a 5.x system, because libm has the same version number in 5.x but is not binary compatible. So the 4.x binary links to libc.so.4 and libm.so.2, and the latter is actually a 5.x library that expects to have __fpclassifyd resolved by linking with libc.so.5. Is it the case on your system that you have old 4.x binaries installed? Kris We need to resolve this before 5.2 in some fashion. It looks like the easiest thing to do is bump libm. Is this advisable? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Sun, Oct 19, 2003 at 03:05:29PM -0600, Scott Long wrote: Kris Kennaway wrote: This symbol is defined in libc.so.5. One way you can see this problem is if you are running a 4.x binary that links to libm.so.2 on a 5.x system, because libm has the same version number in 5.x but is not binary compatible. So the 4.x binary links to libc.so.4 and libm.so.2, and the latter is actually a 5.x library that expects to have __fpclassifyd resolved by linking with libc.so.5. Is it the case on your system that you have old 4.x binaries installed? Kris We need to resolve this before 5.2 in some fashion. It looks like the easiest thing to do is bump libm. Is this advisable? I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Sun, Oct 19, 2003 at 03:13:41PM -0700, Steve Kargl wrote: I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. You don't want to do it before you have to, because this creates more pain for people when you make a change that breaks backwards compat (given the policy/preference of only bumping once per major release). I'm working on a script that will detect the kind of backwards compatibility breakage we're seeing here by comparing the symbols in 4.x and 5.x versions of libraries with the same major revision. We can then run this once a day/week/whatever somewhere to catch these problems as soon as they occur in future. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
On Sun, Oct 19, 2003 at 03:48:58PM -0700, Kris Kennaway wrote: On Sun, Oct 19, 2003 at 03:13:41PM -0700, Steve Kargl wrote: I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. You don't want to do it before you have to, because this creates more pain for people when you make a change that breaks backwards compat (given the policy/preference of only bumping once per major release). I'm working on a script that will detect the kind of backwards compatibility breakage we're seeing here by comparing the symbols in 4.x and 5.x versions of libraries with the same major revision. We can then run this once a day/week/whatever somewhere to catch these problems as soon as they occur in future. You and I participated in the first go around in the library versioning problem. For one of my attempts to discuss this problem, see http://www.freebsd.org/cgi/getmsg.cgi?fetch=1981830+1986079+/usr/local/www/db/text/2002/freebsd-current/20021103.freebsd-current -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
