question about cc

I want to test sin() in program “tm.c” ,so I use the example in help
doc.—sin().
But when I use “cc” compile and link----“cc -o tm tm.c” ,the system tell me
that:

/tmp/AAA175016_cc.o: In function main': /tmp/AAA175016_cc.o(.text+0x1b): undefined reference to _Sin’
cc: /usr/ntox86/bin/ld error 1

I don’t know why?
And the same thing happened when I program with tcp/ip socket api.
Is some system config should be done? and how to do that?

You need to link against the math library for sin(), and the socket
library for tcp/ip apps.
Try:
cc -lm -otm tm.c
and
cc -lsocket -osocketapp socketapp.c

-Peter

zhz_zhang <zhz_zhang@263.net> wrote:

I want to test sin() in program “tm.c” ,so I use the example in help
doc.—sin().
But when I use “cc” compile and link----“cc -o tm tm.c” ,the system tell me
that:

/tmp/AAA175016_cc.o: In function main': /tmp/AAA175016_cc.o(.text+0x1b): undefined reference to _Sin’
cc: /usr/ntox86/bin/ld error 1

I don’t know why?
And the same thing happened when I program with tcp/ip socket api.
Is some system config should be done? and how to do that?

Peter Graves <pgraves@qnx.com> wrote:
: You need to link against the math library for sin(), and the socket
: library for tcp/ip apps.
: Try:
: cc -lm -otm tm.c
: and
: cc -lsocket -osocketapp socketapp.c

Note that the documentation tells you which library you’ll find
each function in.

: zhz_zhang <zhz_zhang@263.net> wrote:
:> I want to test sin() in program “tm.c” ,so I use the example in help
:> doc.—sin().
:> But when I use “cc” compile and link----“cc -o tm tm.c” ,the system tell me
:> that:

:> /tmp/AAA175016_cc.o: In function main': :> /tmp/AAA175016_cc.o(.text+0x1b): undefined reference to _Sin’
:> cc: /usr/ntox86/bin/ld error 1


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

In QNX 4 we could include a #pragma in a header file to designate that a
certain library needed to be included in the link.

This option does not seem to exist in QNX 6. Could it be added?

It would be EXTREAMLY useful!


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Peter Graves” <pgraves@qnx.com> wrote in message
news:a1mnsf$5c2$1@nntp.qnx.com

You need to link against the math library for sin(), and the socket
library for tcp/ip apps.
Try:
cc -lm -otm tm.c
and
cc -lsocket -osocketapp socketapp.c

-Peter

zhz_zhang <> zhz_zhang@263.net> > wrote:
I want to test sin() in program “tm.c” ,so I use the example in help
doc.—sin().
But when I use “cc” compile and link----“cc -o tm tm.c” ,the system tell
me
that:

/tmp/AAA175016_cc.o: In function main': /tmp/AAA175016_cc.o(.text+0x1b): undefined reference to _Sin’
cc: /usr/ntox86/bin/ld error 1

I don’t know why?
And the same thing happened when I program with tcp/ip socket api.
Is some system config should be done? and how to do that?



\

I’m not sure when that would be useful - the last thing I would want is to
have to wade through source code files, removing #pragma 's because they
reference differently named libs on different platforms. Or worse, the
pragma isn’t recognized. Obviously you could conditionally include them,
but all this makes for ugly code. Just my $0.02


Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:a1n2uj$68d$1@inn.qnx.com

In QNX 4 we could include a #pragma in a header file to designate that a
certain library needed to be included in the link.

This option does not seem to exist in QNX 6. Could it be added?

It would be EXTREAMLY useful!


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Peter Graves” <> pgraves@qnx.com> > wrote in message
news:a1mnsf$5c2$> 1@nntp.qnx.com> …
You need to link against the math library for sin(), and the socket
library for tcp/ip apps.
Try:
cc -lm -otm tm.c
and
cc -lsocket -osocketapp socketapp.c

-Peter

zhz_zhang <> zhz_zhang@263.net> > wrote:
I want to test sin() in program “tm.c” ,so I use the example in help
doc.—sin().
But when I use “cc” compile and link----“cc -o tm tm.c” ,the system
tell
me
that:

/tmp/AAA175016_cc.o: In function main': /tmp/AAA175016_cc.o(.text+0x1b): undefined reference to _Sin’
cc: /usr/ntox86/bin/ld error 1

I don’t know why?
And the same thing happened when I program with tcp/ip socket api.
Is some system config should be done? and how to do that?





\

Adam Mallory wrote:

I’m not sure when that would be useful - the last thing I would want is to
have to wade through source code files, removing #pragma 's because they
reference differently named libs on different platforms. Or worse, the
pragma isn’t recognized. Obviously you could conditionally include them,
but all this makes for ugly code. Just my $0.02

I agree, pragmas are ugly, I remain blissfully ignorant of any of them.

The one described seems particularly ugly (reminds me of the Reeses
commercial - “you got build instructions in my source” - although the
result is considerably more distasteful than the chocolate and peanut
butter accident portrayed in the commercial :wink:

OK. I want to jump back in here. When Adam wrote his comment I was willing
to let it slide but now that you are all ganging up on my I want to fight
back. (Please notice that I’m saying that tongue in cheek.)

Agreed, #ifdef’s and #pragma’s are ugly. But they solve a problem.

Would someone suggets that instead of using #ifdef’s that we maintain one
set of source files for one platform and another set of source files for a
different patform? Especially if only a few lines need to be unique for
each platform? I don’t think so!

Personally I would rather do my programming in a program, not a makefile.
Of course there is a place for conditional processing in a makefile. But if
I’m writing software that I want to me as easy as possible for someone else
to use without the need for them to read a lot of documentation, I think
that for the developer to stick a one line #pragma in a header file (which
must be included anyway) is much more efficient (no, to use Robert Krten’s
word, elegent) then to force every developer that would ever use these
routines to have to add several lines to their makefiles. Which by the way
implies that they must know before hand that it is necessary.

So let’s see a show of hands from other programmers.


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Rennie Allen” <rallen@csical.com> wrote in message
news:3C3F4BC0.6060900@csical.com

Adam Mallory wrote:

I’m not sure when that would be useful - the last thing I would want is
to
have to wade through source code files, removing #pragma 's because they
reference differently named libs on different platforms. Or worse, the
pragma isn’t recognized. Obviously you could conditionally include
them,
but all this makes for ugly code. Just my $0.02



I agree, pragmas are ugly, I remain blissfully ignorant of any of them.

The one described seems particularly ugly (reminds me of the Reeses
commercial - “you got build instructions in my source” - although the
result is considerably more distasteful than the chocolate and peanut
butter accident portrayed in the commercial > :wink:

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:a1nk48$i2g$1@inn.qnx.com

Agreed, #ifdef’s and #pragma’s are ugly. But they solve a problem.

Not portably - #pragma itself is portable, but the directive is not.

Would someone suggets that instead of using #ifdef’s that we maintain one
set of source files for one platform and another set of source files for a
different patform? Especially if only a few lines need to be unique for
each platform? I don’t think so!

No but I would suggest a set of makefiles for each build evironment as many
GNU and non-GNU projects do. Or the use of a program to generate a correct
makefile (ie. autoconf etc)

Personally I would rather do my programming in a program, not a makefile.
Of course there is a place for conditional processing in a makefile. But
if
I’m writing software that I want to me as easy as possible for someone
else
to use without the need for them to read a lot of documentation, I think
that for the developer to stick a one line #pragma in a header file (which
must be included anyway) is much more efficient (no, to use Robert Krten’s
word, elegent) then to force every developer that would ever use these
routines to have to add several lines to their makefiles. Which by the
way
implies that they must know before hand that it is necessary.

There is a difference between programming and building. I program in a
languange, I don’t build or link in it - that’s for cc, ld, and make to glue
it all together. I would definately not use the word elegant to describe
the use of pragmas. What’s so wrong with using:

./configure ; make

or make qnx_target, make linux_target, make aix_target etc etc etc…

I don’t see how either (above) would be difficult. The problem with this
one line pragma, is that it tends to lead to other pragmas, and before you
know it… you have a pragma header. Then mulitple pragma headers, which are
conditionally included based on the target. (yuck).

Make is for building, and that’s exactly what it’s great at doing (including
conditional builds)

So let’s see a show of hands from other programmers.

My original post wasn’t meant to be a debate over #pragma (that has been
done over in comp.lang.c, which is a great newsgroup IMHO), but more of a
rationale.

I think you’ll find that while some may agree that one pragma is not much
work - pragmas should be the exception, not the rule.


Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Bill Caroselli <qtps@earthlink.net> wrote:

WAR

OK. I want to jump back in here. When Adam wrote his comment I was willing
to let it slide but now that you are all ganging up on my I want to fight
back. (Please notice that I’m saying that tongue in cheek.)

Agreed, #ifdef’s and #pragma’s are ugly. But they solve a problem.

Would someone suggets that instead of using #ifdef’s that we maintain one
set of source files for one platform and another set of source files for a
different patform? Especially if only a few lines need to be unique for
each platform? I don’t think so!

Partly. I would suggest that common code be placed in common modules, and
then OS specific code be placed in OS specific modules. Paul Trunley’s
“ved” editor did just that. ALL the code that was OS independent was
placed in a variety of modules. Then, code that was OS specific was placed
in .c He ported it to VAX/VMS, QNX 2, QNX 4, and I ported it to
Linux and QNX 6. If something was found not to be portable to a particular
OS, then it was placed into an OS specific module, and anything that referred
to it was OS-independized (if that’s a word :slight_smile:).

The thing that this solves rather nicely is that it eliminates OS and
compiler specific hacks in the source – if OS/X and compiler/Y need some
funky option “#XYZZY” then that option is limited only to .c – if
you need to be anal about it, then -.c :slight_smile:

Personally I would rather do my programming in a program, not a makefile.

Unless the code in the makefile simply compiled everything except the OS
specific modules. For a very educational (though slightly contrary point
of view) take a look at the Kermit sources from Frank da Cruz. All of the
FREAKING FILENAMES are 6 characters long plus the “.c” extension – it’s
super portable…

Of course there is a place for conditional processing in a makefile. But if
I’m writing software that I want to me as easy as possible for someone else
to use without the need for them to read a lot of documentation, I think

… then you’d provide pre-built binaries…

that for the developer to stick a one line #pragma in a header file (which
must be included anyway) is much more efficient (no, to use Robert Krten’s
word, elegent) then to force every developer that would ever use these

<damn, someone who quotes me :slight_smile: Oh hi Bill! :slight_smile:>

routines to have to add several lines to their makefiles. Which by the way
implies that they must know before hand that it is necessary.

Sorry to disagree with you bill, but it’s still a quasi-democracy. I think that
putting in a) compiler specific and b) path specific things in a source file
is a “Bad Thing™”.

So let’s see a show of hands from other programmers.

/WAR

</war mode off :slight_smile:>

Cheers,
-RK


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net



“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3C3F4BC0.6060900@csical.com> …
Adam Mallory wrote:

I’m not sure when that would be useful - the last thing I would want is
to
have to wade through source code files, removing #pragma 's because they
reference differently named libs on different platforms. Or worse, the
pragma isn’t recognized. Obviously you could conditionally include
them,
but all this makes for ugly code. Just my $0.02



I agree, pragmas are ugly, I remain blissfully ignorant of any of them.

The one described seems particularly ugly (reminds me of the Reeses
commercial - “you got build instructions in my source” - although the
result is considerably more distasteful than the chocolate and peanut
butter accident portrayed in the commercial > :wink:


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Consulting and Training at www.parse.com
Email my initials at parse dot com.

Well then, I’ll just take my bat and ball and go home. ;~}

Actually I do want to add one thought (see below).


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Robert Krten” <nospam91@parse.com> wrote in message
news:a1o3l2$ris$1@inn.qnx.com

Of course there is a place for conditional processing in a makefile.
But if
I’m writing software that I want to me as easy as possible for someone
else
to use without the need for them to read a lot of documentation, I think

… then you’d provide pre-built binaries…

Well actually, yes. I give someone a .o or .a and a header file, unless
they want to pay a lot more for my source code.

“Peter Graves” <pgraves@qnx.com> wrote in message
news:a1mnsf$5c2$1@nntp.qnx.com

You need to link against the math library for sin(), and the socket
library for tcp/ip apps.
Try:
cc -lm -otm tm.c
and
cc -lsocket -osocketapp socketapp.c

-Peter

I test it ,it is ok.

Now I have other questions.
1.is "-lsocket "mean the lib named libsocket.so or others?where is it?

2.I want to know that where cc find the lib,in which directory.Can I modify
it or add new lib directory?
How to do that?

3.I have make a lib named libmisc.a.I want my program “tmp.c” compile and
link with the lib I made.
Tmp.c and libmisc.a are in the same directory /tmp

so I use the command:

"cc -lllbmisc.a -o tmp tmp.c "

but the system tell me:

cc -llibmisc.a -o tmp tmp.c

/usr/ntox86/bin/ld: cannot find -llibmisc.a
cc: /usr/ntox86/bin/ld error 1

What shoud I do?



zhz_zhang <> zhz_zhang@263.net> > wrote:
I want to test sin() in program “tm.c” ,so I use the example in help
doc.—sin().
But when I use “cc” compile and link----“cc -o tm tm.c” ,the system tell
me
that:

/tmp/AAA175016_cc.o: In function main': /tmp/AAA175016_cc.o(.text+0x1b): undefined reference to _Sin’
cc: /usr/ntox86/bin/ld error 1

I don’t know why?
And the same thing happened when I program with tcp/ip socket api.
Is some system config should be done? and how to do that?



\

zhz_zhang <zhz_zhang@263.net> wrote:

“Peter Graves” <> pgraves@qnx.com> > wrote in message
news:a1mnsf$5c2$> 1@nntp.qnx.com> …
You need to link against the math library for sin(), and the socket
library for tcp/ip apps.
Try:
cc -lm -otm tm.c
and
cc -lsocket -osocketapp socketapp.c

-Peter

I test it ,it is ok.
Now I have other questions.
1.is "-lsocket "mean the lib named libsocket.so or others?where is it?
That’s what it means.



2.I want to know that where cc find the lib,in which directory.Can I modify
it or add new lib directory?
How to do that?
To add a path to the library search path just update the enviromental variable

LD_LIBRARY_PATH. I.e. export LD_LIBRARY_PATH=$LDLIBRARY_PATH:/path/to/other/libs

3.I have make a lib named libmisc.a.I want my program “tmp.c” compile and
link with the lib I made.
Tmp.c and libmisc.a are in the same directory /tmp

so I use the command:

"cc -lllbmisc.a -o tmp tmp.c "

but the system tell me:

cc -llibmisc.a -o tmp tmp.c

/usr/ntox86/bin/ld: cannot find -llibmisc.a
cc: /usr/ntox86/bin/ld error 1

What shoud I do?

See question two, just add /tmp/ to your search path. As well if
your lib is libmisc.a, you should add just -lmisc not -llibmisc.a

-Peter

“zhz_zhang” <zhz_zhang@263.net> wrote in message
news:a1p3pa$jc4$2@inn.qnx.com

I test it ,it is ok.
Now I have other questions.
1.is "-lsocket "mean the lib named libsocket.so or others?where is it?

Yes, and it’s located in /lib/libsocket.so

2.I want to know that where cc find the lib,in which directory.Can I
modify
it or add new lib directory?
How to do that?

Examine and/or change the environment variable LD_LIBRARY_PATH

3.I have make a lib named libmisc.a.I want my program “tmp.c” compile and
link with the lib I made.
Tmp.c and libmisc.a are in the same directory /tmp

so I use the command:

"cc -lllbmisc.a -o tmp tmp.c "

but the system tell me:

cc -llibmisc.a -o tmp tmp.c

/usr/ntox86/bin/ld: cannot find -llibmisc.a
cc: /usr/ntox86/bin/ld error 1

What shoud I do?

When using a static lib, you need to link against it but don’t use the -l
option - just include it in the list of object file you wish to link
together (watch out, as order matters in terms of symbols defined).

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>