Hi everyone,

Thanks for all the suggestions on my previous post regarding replacing
binaries during execution.

I am getting a few undefined reference errors during compilation. The
error message is:

------
/root/tmp/cc5h04lE.o(.text+0x11ee): In function `main':
/root/init_test/init/main.cpp:596: undefined reference to
`init_auth_itself()'
/root/tmp/cc5h04lE.o(.text+0x11f9):/root/init_test/init/main.cpp:597:
undefined reference to `kernel_auth()'
collect2: ld returned 1 exit status
------

------
# nm *.o | grep auth
00000048 T init_auth_itself
0000003e T kernel_auth
U authunix_create_default
#
------

The two functions are implemented in a different file and I have
included the object file for linking. Is there any limitation in the
number of object files that can be passed for linking purposes. I have
around 20 - 30 object files as input for linking the main binary.

Any suggestions would be really helpful

Karthik

[ Post a follow-up to this message ]

Karthik wrote:

> Hi everyone,
>=20
> Thanks for all the suggestions on my previous post regarding replacing =

> binaries during execution.
>=20
> I am getting a few undefined reference errors during compilation. The=20
> error message is:
>=20
> ------
> /root/tmp/cc5h04lE.o(.text+0x11ee): In function `main':
> /root/init_test/init/main.cpp:596: undefined reference to=20
> `init_auth_itself()'
> /root/tmp/cc5h04lE.o(.text+0x11f9):/root/init_test/init/main.cpp:597:=20
> undefined reference to `kernel_auth()'
> collect2: ld returned 1 exit status
> ------
>=20
> ------
> # nm *.o | grep auth
> 00000048 T init_auth_itself
> 0000003e T kernel_auth
>          U authunix_create_default
> #
> ------
>=20
> The two functions are implemented in a different file and I have=20
> included the object file for linking. Is there any limitation in the=20
> number of object files that can be passed for linking purposes. I have =

> around 20 - 30 object files as input for linking the main binary.
>=20
> Any suggestions would be really helpful
>=20
> Karthik
>=20

20-30 should not pose a problem for any linker.
It may be the order of references.

See man pagers for lorder(1) and tsort(1)



--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

[ Post a follow-up to this message ]

Karthik <karthik@nospam.com> writes:

> I am getting a few undefined reference errors during compilation.

You don't. You get an error message during *linking*

> /root/tmp/cc5h04lE.o(.text+0x11ee): In function `main':
> /root/init_test/init/main.cpp:596: undefined reference to
> `init_auth_itself()'

The 'nm' output you've posted indicates that the missing functions
have 'extern "C"' linkage. Unresolved references come from C++ code.

Do the "problem" functions have 'extern "C"' when they are prototyped
in main.cpp ? Probably not ...

> Is there any limitation in the
> number of object files that can be passed for linking purposes. I have
> around 20 - 30 object files as input for linking the main binary.

There is a limitation on total command-line length. If you exceed
that limit, make or your shell will fail with 'argument list too
long'.

You did not specify what system you've done this on, but it looks
like Linux, where the command-line-limit is almost 32 pages
(128KBytes) long. We can safely assume you did not hit that limit.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

>
> The 'nm' output you've posted indicates that the missing functions
> have 'extern "C"' linkage. Unresolved references come from C++ code.
>
> Do the "problem" functions have 'extern "C"' when they are prototyped
> in main.cpp ? Probably not ...
>
>

The problem was not including both the functions inside the extern "C"
linkage. I had 12 other functions which i had in there but forogt to
include these functions within the linkage structure. [should'nt work
late in the nights !]

It was interesting to note how you determined form the output of nm that
these functions require extern "C" linkage. !! i read the man page and
could'nt find any references of how to determine those. Can you give me
some insight on this ?

Thanks

Karthik

[ Post a follow-up to this message ]

Karthik <karthik@nospam.com> writes:

> It was interesting to note how you determined form the output of nm
> that these functions require extern "C" linkage. !! i read the man
> page and could'nt find any references of how to determine those. Can
> you give me some insight on this ?

The way C++ (usually) implements function overloading is via
name-mangling, that is by encoding parameter types into the
function name.

Thus, when you compile

void foo(void) {}
void foo(int) {}
void foo(long) {}

the nm output looks like this (g++-2.9x):
0000000c T foo__Fi
00000018 T foo__Fl
00000000 T foo__Fv

or like this (g++-3.x):
00000006 T _Z3fooi
0000000c T _Z3fool
00000000 T _Z3foov

Other C++ compilers use similar schemes. Your symbols were not so
adorned, which led me to the conclusion that they have "C" linkage.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]