struct point not identified by gcc

[Keith Thompson]

This doesn't have anything much to do with gcc. Before gcc was
thought of, unix needed -lm to link the maths library, and today the
Mac I'm using doesn't need -lm even though its compiler is gcc.

<OT>
Are you sure about the latter? I tried a small test program that
computes sqrt(2.0) and it didn't require "-lm" because gcc was smart
enough to compute the value at compilation time. Try something like
sqrt(time(NULL)); it's a silly thing to compute, but it should prevent
the compiler from optimizing away the sqrt() call.
</OT>

 

[CBFalconer]

I wrote a simply program with a 3 D coordinate called point. I am
adding two points, taking their distance etc. gcc compiler is not
identifying the struct. Here is the code. I get bunch of errors. The
main ones are : useless storage class specifier in empty declaration,
'point' undeclared (first use in this function), 'p1' undeclared
(first use in this function) etc. Any help will be appreciated. Thanks

#include <stdio.h>
#include <math.h>

/* create a 3d point struct*/
typedef struct point{
int x,y,z;
};

Well, you might consider giving the typedef a name to define as
"struct point". The name "point" would agree with the other code.

 

[DanielJohnson]

San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

I did the same thing, i.e. wrote a small program and sqrt just worked
fine without -lm switch. Whats the matter ?, but in my previous
program it did require me to do the -lm switch.

 

[Keith Thompson]

I did the same thing, i.e. wrote a small program and sqrt just worked
fine without -lm switch. Whats the matter ?, but in my previous
program it did require me to do the -lm switch.

It's usually more helpful to quote the relevant context and *not* the
signature.

Probably the compiler was able to compute sqrt() at compile time,
avoiding the need to use the math library at run time.

But it's not really a C question; it's about a specific compiler. Try
looking at an assembly listing, or posting to a system-specific
newsgroup (if you're using gcc, try gnu.gcc.help).

 

[Dik T. Winter]

....
[ about sqrt findable without specific switch.]

> But it's not really a C question; it's about a specific compiler.

It is not about the compiler either. It is about the OS. When the
standard C library supplied on the OS contains sqrt, the switch is
not needed. When that library does *not* contain sqrt, the switch
is needed (unless the compiler can calculate the value compile-time).

Originally on Unix the standard C library did *not* contain the math
functions, so you had to supply the -lm switch. But in some versions
the two libraries are unified to a single library.

 

[Richard Bos]

...
[ about sqrt findable without specific switch.]

But it's not really a C question; it's about a specific compiler.

It is not about the compiler either. It is about the OS. When the
standard C library supplied on the OS contains sqrt,

No, it's about the implementation. Some implementations are delivered
complete, with the library and the compiler; some are delivered
piecemeal, with the compiler hoping and praying that someone sent a
library along with the OS, and that perhaps they can form a valid C
implementation together.

Richard

 

[Richard Tobin]

This doesn't have anything much to do with gcc. Before gcc was
thought of, unix needed -lm to link the maths library, and today the
Mac I'm using doesn't need -lm even though its compiler is gcc.

[/QUOTE]

Are you sure about the latter? I tried a small test program that
computes sqrt(2.0) and it didn't require "-lm" because gcc was smart
enough to compute the value at compilation time.

Yes, I made exactly that mistake - I even used sqrt(2.0).

Try something like
sqrt(time(NULL)); it's a silly thing to compute, but it should prevent
the compiler from optimizing away the sqrt() call.

But in fact that still works without -lm.

-- Richard

 

[santosh]

Are you sure about the latter? I tried a small test program that
computes sqrt(2.0) and it didn't require "-lm" because gcc was smart
enough to compute the value at compilation time.

Yes, I made exactly that mistake - I even used sqrt(2.0).

Try something like
sqrt(time(NULL)); it's a silly thing to compute, but it should prevent
the compiler from optimizing away the sqrt() call.

But in fact that still works without -lm.[/QUOTE]

Then either the compiler has an intrinsic for sqrt or else the latter
is present in the same library that contains the non-math standard C
functions. Also maybe the environment is secretly supplying the
library option?

 

[Nils Weller]

DanielJohnson a écrit :
You need the -lm switch when using the gcc software. This switch is
never used in other compilers not under unix, that are smart enough to
including the C math functions by default.

We have often discussed here this msfeature of gcc but they will never
change it as it seems.

You cannot remove historical quirks like this without breaking
anything, especially if they've been almost universial practice
for a couple of decades. I've considered adding -lm by default
to my compiler as well, but I figured this would end up doing
the users a disservice. Because if you write build scripts for
a compiler which does not require you to link that library
explicitly, then chances are your project will break if you
use it with a different compiler.

In that case the time you have to deal with this problem is
just deferred until a later date. So I think it's best to have
to encounter, recognize, and fix this problem as early as
possible.

It's not just compilers by different vendors that would be
affected, but also older versions of a compiler that recently
abandoned this requirement. If gcc comes out with a new
release that always links with that library by default, as you
you suggest, then code developed with that compiler version is
more likely not to build with older versions.

There are many other more system-specific libraries that can
break the necks of developers, such as the networking libraries
you explicitly have to link with on Solaris/UnixWare/Reliant,
and then there are realtime, threading and dynamic linking libs
you need on some Unices, which tend to be very inconsistent.
You may also run into problems with weak empty function stubs
in a Unix standard C library object, which make it seem like you
don't have to link with any other libs when in fact you do.

I've given some thought to this topic as well, and one approach
that came to my mind, is to have the linker or compiler give
you more info than ``symbol x is undefined!''. Maybe we should
have some sort of database of all standard library functions
available on a given system. Then the linker error message
could read ``symbol x undefined (but available in /usr/lib/x.so:
add -lx to the linker flags!)'' instead.

I'm currently doing some ELF file access code, and maybe I'll
also end up writing a linker, so I may play with such a symbol
database some time soon. In general, though, I feel that system
library dependencies are already a terrible battlefield which
would benefit immensely from preserving at least a tiny bit of
consistency across multiple platforms and compilers.

(BTW, if I recall correctly, AIX by default does not even
install the math library, so a compiler that unconditionally
links with it would have an unneeded dependency.)

 

[jacob navia]

Nils Weller a écrit :

You cannot remove historical quirks like this without breaking
anything, especially if they've been almost universial practice
for a couple of decades. I've considered adding -lm by default
to my compiler as well, but I figured this would end up doing
the users a disservice. Because if you write build scripts for
a compiler which does not require you to link that library
explicitly, then chances are your project will break if you
use it with a different compiler.

Wrong!
They would say

What a bad compiler this one. It needs an explicit -lm switch.
And the builders of the other compiler would say
Mmmm many users are complaining that the xxx compiler does NOT
need the -lm switch... Should we include it by default?

In that case the time you have to deal with this problem is
just deferred until a later date. So I think it's best to have
to encounter, recognize, and fix this problem as early as
possible.

That is why no progress is done in unix... Old bugs are preserved
for posterity. The "make" utility needs a tab as the first char
in an action line. If you put spaces it will not recognize the
line and say:

Missing separator in rules. Stop.

This BUG has been in all unices since at least 1983, when I saw the
first one, and was bitten by this bug.

It's not just compilers by different vendors that would be
affected, but also older versions of a compiler that recently
abandoned this requirement. If gcc comes out with a new
release that always links with that library by default, as you
you suggest, then code developed with that compiler version is
more likely not to build with older versions.

So what?

There are many other more system-specific libraries that can
break the necks of developers, such as the networking libraries
you explicitly have to link with on Solaris/UnixWare/Reliant,
and then there are realtime, threading and dynamic linking libs
you need on some Unices, which tend to be very inconsistent.
You may also run into problems with weak empty function stubs
in a Unix standard C library object, which make it seem like you
don't have to link with any other libs when in fact you do.

I've given some thought to this topic as well, and one approach
that came to my mind, is to have the linker or compiler give
you more info than ``symbol x is undefined!''. Maybe we should
have some sort of database of all standard library functions
available on a given system. Then the linker error message
could read ``symbol x undefined (but available in /usr/lib/x.so:
add -lx to the linker flags!)'' instead.

I have given also much thought to this, and I have developed a
database that is used by the IDE. When it detects a message like
"undefined external reference" it wil look at the database and
propose the libraries to the user...

I'm currently doing some ELF file access code, and maybe I'll
also end up writing a linker, so I may play with such a symbol
database some time soon. In general, though, I feel that system
library dependencies are already a terrible battlefield which
would benefit immensely from preserving at least a tiny bit of
consistency across multiple platforms and compilers.

Yeah, but a more modern approach than the 1980 approach would be useful.
I wrote a linker for lcc-win32 under windows, and added most common
libraries to it automatically...
Not a big deal.

(BTW, if I recall correctly, AIX by default does not even
install the math library, so a compiler that unconditionally
links with it would have an unneeded dependency.)

I am working with AIX version too. Great system but needs some
more user friendliness.


jacob

 

[Richard Tobin]

Yes, I made exactly that mistake - I even used sqrt(2.0).


But in fact that still works without -lm.

[/QUOTE]

Then either the compiler has an intrinsic for sqrt or else the latter
is present in the same library that contains the non-math standard C
functions. Also maybe the environment is secretly supplying the
library option?

Foiled again, it's using an inline instruction for sqrt. So this time
I changed it to tgamma(time(0)), on the assumption that not even the
latest Intel processors have a gamma instruction, and it *still*
doesn't need -lm. Looking at the output of gcc -S and gcc -v, it
appears to be calling a function and linking to a library "-lSystem",
which includes the maths functions.

-- Richard

 

[Nils Weller]

Good evening,

Nils Weller a écrit :

Wrong!
They would say

What a bad compiler this one. It needs an explicit -lm switch.

Well, they may not appreciate it, but it would be "for their own
good". ;-)

This isn't a big deal anyway because compilers are already
incompatible in lots of other ways, and I can see where you're
coming from. But myself I would prefer to be warned about such
potential problems, and I can see good reasons for not changing
this particular oddity.

(It would also be nice to get warnings about functions with
dangerously nonportable semantics, such as the signal()
function which is still broken on most System V derivatives,
but that's another story ...)

And the builders of the other compiler would say
Mmmm many users are complaining that the xxx compiler does NOT
need the -lm switch... Should we include it by default?

Yes, this is not a fortunate situation. But you see, there is so
much existing practice that you can't get everyone to change this
without running into new problems. That's all I was saying. If
you get gcc to change, you'd still have to get lots and lots of
other Unix compilers to change, and lots of users to update their
gcc versions.

So what?

That would impose another implicit (and probably unexpected)
compiler version dependency on your software. The confusion would
be shifted from the developer to the end users, who you shouldn't
expect to have the most up-to-date compiler version available to
compile your stuff.

That would suck.

I have given also much thought to this, and I have developed a
database that is used by the IDE. When it detects a message like
"undefined external reference" it wil look at the database and
propose the libraries to the user...
Good!

I am working with AIX version too. Great system but needs some
more user friendliness.

True. Would also have been nice if it didn't force all-position-
independent code down everyone's throat.

 

[santosh]

Then either the compiler has an intrinsic for sqrt or else the latter
is present in the same library that contains the non-math standard C
functions. Also maybe the environment is secretly supplying the
library option?

Foiled again, it's using an inline instruction for sqrt. So this time
I changed it to tgamma(time(0)), on the assumption that not even the
latest Intel processors have a gamma instruction, and it *still*
doesn't need -lm. Looking at the output of gcc -S and gcc -v, it
appears to be calling a function and linking to a library "-lSystem",
which includes the maths functions.[/QUOTE]

Hmm..., curious system, (which one?.) This is a case in point for the
argument to keep this group loosely bound to ISO C.

 

[Mark McIntyre]

That is why no progress is done in unix... Old bugs are preserved
for posterity.

right - that'll be why unix and unix clones are so unsuccessful then.

The "make" utility needs a tab as the first char
in an action line. If you put spaces it will not recognize the
line

Apparently you have a /really/ old version of make.

This BUG has been in all unices since at least 1983,

A bug is when something doesn't behave like its supposed to. Ever used
a fortran compiler? Rry sticking a C character at column seven. Theres
a bug that means it skips that line, apparently.

As it happens, I think the need to put -lm in on some versions of gcc
and some osen is a bit annoying, but its hardly a bug, any more than
having to use vi is a bug, or some versions of SQL not liking iif()
statements. Its just How That Platform Works (tm).
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Tobin]

Hmm..., curious system, (which one?.)

Just a current Mac.

-- Richard

 

[Keith Thompson]

Nils Weller a écrit :

Wrong!
They would say

What a bad compiler this one. It needs an explicit -lm switch.
And the builders of the other compiler would say
Mmmm many users are complaining that the xxx compiler does NOT
need the -lm switch... Should we include it by default?

Oh, no, I have to type an extra 3 characters!

Most C compilers are not conforming by default; you have to specify
extra options to make then conform to the standard. I agree that the
need for "-lm" is annoying, but I just don't worry about it that much.

That is why no progress is done in unix... Old bugs are preserved
for posterity. The "make" utility needs a tab as the first char
in an action line. If you put spaces it will not recognize the
line and say:

Missing separator in rules. Stop.

This BUG has been in all unices since at least 1983, when I saw the
first one, and was bitten by this bug.

So you haven't actually been bitten by it since 1983? And what does a
misfeature in "make" have to do with C?

(I don't know whether correcting this might break some existing
Makefiles. Discuss in comp.unix.programmer if you're interested.)

So what?

So code developed with that compiler version is more likely not to
build with older versions.

[...]

 

[Keith Thompson]

right - that'll be why unix and unix clones are so unsuccessful then.


Apparently you have a /really/ old version of make.

[...]

<OT>
Not necessarily. GNU Make 3.81, the latest version, is less than a
year old. (It at least suggests using a tab rather than 8 spaces.)
</OT>

 

[Randy Howard]

How did you miss this when you read the C-FAQ:

14.3: I'm trying to do some simple trig, and I am #including <math.h>,
but I keep getting "undefined: sin" compilation errors.

A: Make sure you're actually linking with the math library. For
instance, under Unix, you usually need to use the -lm option, at
the *end* of the command line, when compiling/linking. See also
questions 13.25, 13.26, and 14.2.

You will notice that it doesn't actually answer his question.
Specifically, "Do i always" ...

And the answer is no, but if you are using any of the math functions
which require it, then yes obviously for a given program.

 

[Randy Howard]

Its not a gcc-ism, please don't mischaracterise it. You're probably
aware that all DOS compilers exhibited this same feature for many
years. I think some early Windows ones even did it (certainly C6 and
Watcom's C compiler did, even when compiling windows-compatible code).
The reason, as far as I recall, is their roots in hardware that didn't
provide floating point support.

You had the option to pick what type of math implementation you wanted
to link against, software fp emulation, 8087, Weitek, 68881/2, etc. I
wonder if lcc-win32 can generate code for a Weitek coprocessor?

 

[CBFalconer]

Its not a gcc-ism, please don't mischaracterise it. You're probably
aware that all DOS compilers exhibited this same feature for many
years. I think some early Windows ones even did it (certainly C6
and Watcom's C compiler did, even when compiling windows-compatible
code). The reason, as far as I recall, is their roots in hardware
that didn't provide floating point support.

You had the option to pick what type of math implementation you
wanted to link against, software fp emulation, 8087, Weitek,
68881/2, etc. I wonder if lcc-win32 can generate code for a
Weitek coprocessor?[/QUOTE]

I doubt it. It won't run on a 486 (at least the debugger portion).

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews