Re: [avr-gcc-list] FAQ (was: strange behaviour with ceil())

[Sander Pool]

Ted,

if you specify -lm -lc on the gcc command line won't it search libm before
it searches libc? That way you could have all math symbols in libc but still
allow for dedicated implmentations to be used.

In any case, I don't see an issue with using -lm if I use math routines.
Reminds me of the old Unix days :-) So no need to change the libraries on my
account.

It's interesting to remember the hardware our fore-fathers used to develop
software. There really isn't a reason why we can't build a fully functional
computer with compiler and OS all running together on a mega128. And have
multiple people log into it at the same time. When I was taught Pascal on a
VAX-750 about 18 years ago we had dozens of people connected to it.
Performance sucked but it got the job done :-)

    Sander

----- Original Message -----
From: "Theodore Roth" <address@hidden>
To: "Joerg Wunsch" <address@hidden>
Cc: "AVR GCC List" <address@hidden>; "Marek Michalkiewicz"
<address@hidden>
Sent: Monday, July 29, 2002 9:48 AM
Subject: Re: [avr-gcc-list] FAQ (was: strange behaviour with ceil())


>
>
> On Mon, 29 Jul 2002, Joerg Wunsch wrote:
>
> :) (Distinction between space and tab in Makefiles)
> :)
> :) > As a side note, I would put forth the argument that any program
> :) > should not make a distinction between TABS and SPACES.
> :)
> :) Sure, but that's a merely historical point with the Unix make utility.
> :) It's a bit too late to really change this now. ;-) (Although GNU make
> :) does its best to allow for both forms, but see my initial posting,
> :) relying on this will make a Makefile artificially incompatible with
> :) other versions of make.)
>
> You're not a true Unix programmer until you've had to hunt down some
> spaces in a makefile that should be tabs. ;-) Not a pleasant experience
> with older versions of make (Xenix-286 had the worst error messages I've
> ever seen). Gnu-make seems to make it almost tolerable. If you edit a
> makefile in emacs with color syntax hilighting on, it will color the bogus
> spots for you.
>
> :) The Unix fathers were a bit lazy in typing.  (Actually, their
> :) typewriters were running at 100 Baud, so they could only type 10
> :) characters per second.)  This made them chose short command names, and
> :) short filenames.  Thus, many standard filename suffixes in Unix are
> :) single-letter only.
>
> So true.
>
> :) > What is the down side in combining them?
> :)
> :) My guess is that the initial reason for having them in separated
> :) libraries were rather the address space limitations of the PDP-11 Unix
> :) originates from.  By splitting off the mathematical library from the
> :) remainder of the C library, they could overcome the effects of the
> :) small 64 KB data address space.
>
> I think this is part of the reason...
>
> :)
> :) These days, it's IMHO not warranted to really have two separate
> :) libraries.  I'm all for it to combine all the functions in a single
> :) libc.a, and ship an empty libm.a for compatibility (to not break
> :) Makefiles that already use "-lm".)
> :)
> :) Marek and Ted, what do you think about it?
>
> I could go either way on this. Considering that glibc has almost
> everything in libc.so now a days, it's probably not totally unacceptable.
> The only reason I can come up with for the continued separation of libm
> from libc is that it makes it easier to link against a different libm,
> which might have custom tuned, higher performance versions of the math
> library. You would then only need to change -L at link time to pull in
> new libm.
>
> I need to study up on what the link editor does and how it searches
> archives before I can give an answer that isn't just hand waving.
>
> In the end, it might be best to continue with tradition.
>
> :)
> :) > So perhaps a general AVR GCC FAQ is needed.
> :)
> :) I already volunteered to maintain it. ;-)
>
> And I would have commited it to cvs last night, but had an unexpected
> visitor which lead to the drinking of too much beer...
>
>
> Ted Roth
>
> avr-gcc-list at http://avr1.org
>

avr-gcc-list at http://avr1.org