Compiling HAT sample program failed..

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

Hi, I would like to know why couldn’t I compile sample program from High
Availability Toolkit? Seems like the compiler/linker is unable to recognize
the libham.a library. I’ve just upgraded our PE installation from 6.2.0 to
6.2.1. Previously (6.2.0) I tried to compile the HAM sample program using
the halibc, and it was OK. Any changes? Where could I find information
related to this problem?

TIA…
–meph++

2

Please send us your build session console output.

Alex Chapiro

“Mephri” <mephri@infolink.co.id> wrote in message
news:bh9i2f$3uc$1@inn.qnx.com…

Hi, I would like to know why couldn’t I compile sample program from High
Availability Toolkit? Seems like the compiler/linker is unable to
recognize
the libham.a library. I’ve just upgraded our PE installation from 6.2.0 to
6.2.1. Previously (6.2.0) I tried to compile the HAM sample program using
the halibc, and it was OK. Any changes? Where could I find information
related to this problem?

TIA…
–meph++
\

3

Mephri <mephri@infolink.co.id> wrote:

Hi, I would like to know why couldn’t I compile sample program from High
Availability Toolkit? Seems like the compiler/linker is unable to recognize
the libham.a library. I’ve just upgraded our PE installation from 6.2.0 to
6.2.1. Previously (6.2.0) I tried to compile the HAM sample program using
the halibc, and it was OK. Any changes? Where could I find information
related to this problem?

Are you sure it was the libham.a causing problems? With 6.2.1 (A),
libha.a was broken, so one couldn’t link against it. PR 15814
reports this problem.

I didn’t have a problem with libham.a, though.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

4

Here is the session snapshot:

[maverick@XTS_RD:~/Projects/HAT/ExmplTest:526]
$ cc -L/usr/lib -I/usr/include -lham -lha -o addinet addinet.c
/tmp/AAA770082_cc.o: In function main': /tmp/AAA770082_cc.o(.text+0x6d): undefined reference to ham_connect’
/tmp/AAA770082_cc.o(.text+0x89): undefined reference to ham_attach' /tmp/AAA770082_cc.o(.text+0xa9): undefined reference to ham_condition’
/tmp/AAA770082_cc.o(.text+0xcb): undefined reference to ham_action_restart' /tmp/AAA770082_cc.o(.text+0x11a): undefined reference to ham_disconnect’
cc: /usr/bin/ntox86-ld error 1

I got the addinet.c from the QNX Documentation (HelpViewer), High
Availability Toolkit section.

–meph++

“Alex Chapiro” <achapiro@qnx.com> wrote in message
news:bhak6l$r9h$1@inn.qnx.com…

Please send us your build session console output.

Alex Chapiro

“Mephri” <> mephri@infolink.co.id> > wrote in message
news:bh9i2f$3uc$> 1@inn.qnx.com> …
Hi, I would like to know why couldn’t I compile sample program from High
Availability Toolkit? Seems like the compiler/linker is unable to
recognize
the libham.a library. I’ve just upgraded our PE installation from 6.2.0
to
6.2.1. Previously (6.2.0) I tried to compile the HAM sample program
using
the halibc, and it was OK. Any changes? Where could I find information
related to this problem?

TIA…
–meph++


\

5

Mephri <mephri@infolink.co.id> wrote:

Here is the session snapshot:

[maverick@XTS_RD:~/Projects/HAT/ExmplTest:526]
$ cc -L/usr/lib -I/usr/include -lham -lha -o addinet addinet.c
/tmp/AAA770082_cc.o: In function main': /tmp/AAA770082_cc.o(.text+0x6d): undefined reference to ham_connect’
/tmp/AAA770082_cc.o(.text+0x89): undefined reference to ham_attach' /tmp/AAA770082_cc.o(.text+0xa9): undefined reference to ham_condition’
/tmp/AAA770082_cc.o(.text+0xcb): undefined reference to ham_action_restart' /tmp/AAA770082_cc.o(.text+0x11a): undefined reference to ham_disconnect’
cc: /usr/bin/ntox86-ld error 1

I got the addinet.c from the QNX Documentation (HelpViewer), High
Availability Toolkit section.

If you re-order you commandline it will work fine:

machine-1$ cc -L/usr/lib -I/usr/include -lham -lha -o addinet addinet.c
/tmp/AAA832260_cc.o: In function main': /tmp/AAA832260_cc.o(.text+0x6d): undefined reference to ham_connect’
/tmp/AAA832260_cc.o(.text+0x89): undefined reference to ham_attach' /tmp/AAA832260_cc.o(.text+0xa9): undefined reference to ham_condition’
/tmp/AAA832260_cc.o(.text+0xcb): undefined reference to ham_action_restart' /tmp/AAA832260_cc.o(.text+0x11a): undefined reference to ham_disconnect’
cc: /usr/bin/ntox86-ld error 1

machine-1$ cc addinet.c -L/usr/lib -I/usr/include -lham -lha -o addinet
machine-1$ ls -l addinet
-rwxrwxr-x 1 peterm techies 14138 Aug 13 10:02 addinet*

Peter

–meph++

“Alex Chapiro” <> achapiro@qnx.com> > wrote in message
news:bhak6l$r9h$> 1@inn.qnx.com> …
Please send us your build session console output.

Alex Chapiro

“Mephri” <> mephri@infolink.co.id> > wrote in message
news:bh9i2f$3uc$> 1@inn.qnx.com> …
Hi, I would like to know why couldn’t I compile sample program from High
Availability Toolkit? Seems like the compiler/linker is unable to
recognize
the libham.a library. I’ve just upgraded our PE installation from 6.2.0
to
6.2.1. Previously (6.2.0) I tried to compile the HAM sample program
using
the halibc, and it was OK. Any changes? Where could I find information
related to this problem?

TIA…
–meph++

6

Ha-ha… Strange it is. Could you tell me why this happens?

–meph++

“Peter Martin” <peterm@qnx.com> wrote in message
news:bhdggq$g7v$1@nntp.qnx.com…

If you re-order you commandline it will work fine:

machine-1$ cc -L/usr/lib -I/usr/include -lham -lha -o addinet addinet.c
/tmp/AAA832260_cc.o: In function main': /tmp/AAA832260_cc.o(.text+0x6d): undefined reference to ham_connect’
/tmp/AAA832260_cc.o(.text+0x89): undefined reference to ham_attach' /tmp/AAA832260_cc.o(.text+0xa9): undefined reference to ham_condition’
/tmp/AAA832260_cc.o(.text+0xcb): undefined reference to
ham_action_restart' /tmp/AAA832260_cc.o(.text+0x11a): undefined reference to ham_disconnect’
cc: /usr/bin/ntox86-ld error 1

machine-1$ cc addinet.c -L/usr/lib -I/usr/include -lham -lha -o addinet
machine-1$ ls -l addinet
-rwxrwxr-x 1 peterm techies 14138 Aug 13 10:02 addinet*

Peter

7

Mephri <mephri@infolink.co.id> wrote:

Ha-ha… Strange it is. Could you tell me why this happens?

GCC linking is a one-pass operation through the provided object/libraries.
They thus must be ordered so that undefineds introduced by one module can
be resolved by contents of following ones (otherwise they are not undefined
so aren’t pulled out of the library if it is encountered first). I think a
special-case is made for ‘-lc’, and you can do some funky things with ‘()’,
but that is the general rule … link order is important.

To quote from the online GCC docs for “-llibrary”:

It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order
they are specified. Thus, foo.o -lz bar.o searches library z after file
foo.o but before bar.o. If bar.o refers to functions in z, those
functions may not be loaded.