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_scal
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
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:
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 l
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
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 w
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 debuggi
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 f
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
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
l
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 stil
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
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 stil
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/l
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:
>
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/
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()
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()
> specific
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.
[ 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 go
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.
> &
//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
of symbol tampering.
> >
> > Warner ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
> > send any mail to "[EMAIL PROTECTED]"
> >
>
&g
MAIL 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 mak
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
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 lib
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
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 lib
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
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
ersion 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
e-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
e-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
in/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
/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
003 09:19:07 -0700
> Steve Kargl <[EMAIL PROTECTED]> wrote:
>
> > Are you linking in libc?
> >
> > troutmask:kargl[207] nm -D /usr/lib/libc.so | grep fpcl
> > 000b0040 T __fpclassifyd
> > 000afff0 T __fpclassifyf
> > 000b00a0 T __fpclassifyl
>
&g
On Fri, 29 Aug 2003 09:19:07 -0700
Steve Kargl <[EMAIL PROTECTED]> wrote:
> Are you linking in libc?
>
> troutmask:kargl[207] nm -D /usr/lib/libc.so | grep fpcl
> 000b0040 T __fpclassifyd
> 000afff0 T __fpclassifyf
> 000b00a0 T __fpclassifyl
I think the problem is
d still get this
> > sh apache.sh start
> > Syntax error on line 237 of /usr/local/etc/apache/httpd.conf:
> > Cannot load /usr/local/libexec/apache/libphp4.so into server:
> > /usr/local/libexec/apache/libphp4.so: Undefined symbol "__fpclassifyd"
> >
> &g
/apache/libphp4.so into server:
> /usr/local/libexec/apache/libphp4.so: Undefined symbol "__fpclassifyd"
>
> I'm pretty sure that my binaries are in sync. A dangling libraries somewhere?
Something is probably out of date, but I don't know whether it's
Apache or
d.conf:
> Cannot load /usr/local/libexec/apache/libphp4.so into server:
> /usr/local/libexec/apache/libphp4.so: Undefined symbol "__fpclassifyd"
>
> I'm pretty sure that my binaries are in sync. A dangling libraries somewhere?
I see something similar. I tried to recompile c
: Undefined symbol "__fpclassifyd"
I'm pretty sure that my binaries are in sync. A dangling libraries somewhere?
--
Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/l
41 matches
Mail list logo
