[uClibc]long long functions in stdlib

Jason Huang Jason.Huang at WesconGroup.com
Tue Jul 9 23:01:41 UTC 2002


Greetings.

I did not have the problem last yesterday. I made a fresh update from
cvs.uclinux.org and it complained '__a' in libc/stdlib/drand48_iter.c. I
guess someone put this drand48 in without checking against no-long-long.

What I did was modifying (temporarily) libc/stdlib/Makefile:
ifeq ($(HAS_LONG_LONG),true)
CSRC += drand48_ ...
endif

I hope someone fixes in the cvs.

Jason

-----Original Message-----
From: uclibc-admin at uclibc.org [mailto:uclibc-admin at uclibc.org] On Behalf
Of mjn3 at codepoet.org
Sent: Tuesday, July 09, 2002 3:03 PM
To: Beaulieu, James A.
Cc: uclibc at uclibc.org
Subject: Re: [uClibc]long long functions in stdlib


Hello,

On Tue, Jul 09, 2002 at 11:10:55AM -0400, Beaulieu, James A. wrote:
> Greetings.
> 
> When you build without long long support, the two stdlib functions:
> __drand48_iterate()
> srand48_r()
> fail with they operate on the drand48_data structure. This structure
> properly has the long long __a variable removed, but the above
functions 
> try to operate on __a anyways. There has to be a rework of the
functions 
> to support the lack of a long long construct.

Yes.  I started dealing with "no long long" issues last week and haven't
gotten back to it.  I probably won't get to it for a couple of weeks, as
it is stuff I'm doing in my spare time (connected with my bcc/elks
port).  There are a number of places that need fixing.

Do you have a pressing need to build without long long support?

Manuel

_______________________________________________
uClibc mailing list
uClibc at uclibc.org
http://uclibc.org/mailman/listinfo/uclibc

Tracking #: C0AE8232D381E64ABFF6F4CED9384ADF107BA798
Message Filter




More information about the uClibc mailing list