[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