Unix Programming - linking problem

Author

linking problem

gunvant.k.patil@gmail.com

2007-03-28, 7:18 am

Hi All,

I am trying to build a binary using gcc version 3.4.5 20051201 (Red
Hat 3.4.5-2) and got following sort of warnings

/usr/home/gpatil/mirasrc/007/obj/mira/lib/distrib/
libmira.a(mira_util.o)(.text+0x3a9): In function `mira_seteuid':
/usr/home/gpatil/mirasrc/007/src/mira/lib/libmira/mira_util.c:320:
warning: Using 'getpwnam' in statically linked applications requires
at runtime the shared libraries from the glibc version used for
linking
/usr/home/gpatil/mirasrc/007/obj/mira/lib/distrib/libmira.a(idmatch.o)
(.text+0x500): In function `hostaddr':
/usr/home/gpatil/mirasrc/007/src/mira/lib/libmira/../libgulp/idmatch.c:
298: warning: Using 'gethostbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used
for linking

Any idea how to eliminate these?
Although binary is builded successfully but it doesn't seems have
symbol info of static functions in code thats driving me crazy while
debugging it

Any help in this regard will be appreciated

-Cheers,
Gunvant
~~~~~~~~~~~~~~
No trees were killed in the sending of this message. However a large
number of electrons were terribly inconvenienced.

Paul Pluzhnikov

2007-03-28, 1:18 pm

"gunvant.k.patil@gmail.com" <gunvant.k.patil@gmail.com> writes:

> libmira.a(mira_util.o)(.text+0x3a9): In function `mira_seteuid':
> /usr/home/gpatil/mirasrc/007/src/mira/lib/libmira/mira_util.c:320:
> warning: Using 'getpwnam' in statically linked applications requires
> at runtime the shared libraries from the glibc version used for
> linking
....
> Any idea how to eliminate these?

Do not link statically. Static linking against system libraries is
bad idea(TM) on any modern UNIX, and especially bad idea on Linux.

It is often done in the mistaken belief that the executable will run
on other OS releases, but in fact it makes the resulting executable
much *less* portable.

> Although binary is builded successfully but it doesn't seems have
> symbol info of static functions in code thats driving me crazy while
> debugging it

That has nothing to do with the warning above.
You'll need to describe that problem in some detail if you want
help with that.

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

gunvant.k.patil@gmail.com

2007-03-29, 7:19 am

On Mar 28, 7:15 pm, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
wrote:
> "gunvant.k.pa...@gmail.com" <gunvant.k.pa...@gmail.com> writes:
> ...
>
> Do not link statically. Static linking against system libraries is
> bad idea(TM) on any modern UNIX, and especially bad idea on Linux.

Thanks

> It is often done in the mistaken belief that the executable will run
> on other OS releases, but in fact it makes the resulting executable
> much *less* portable.
>
>
> That has nothing to do with the warning above.
> You'll need to describe that problem in some detail if you want
> help with that.

I have few static functions (ex. readlog()) in source code,
nm smtplog | grep readlog or
objdump -tD smtplog | grep readlog
result is nothing means this symbol is not present in binary. its
happening for all static functions. other normal function symbols are
present.
hence i can't set breakpoints on static functions in gdb while it
works fine for normal functions.

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

Paul Pluzhnikov

2007-03-29, 7:19 am

"gunvant.k.patil@gmail.com" <gunvant.k.patil@gmail.com> writes:

> I have few static functions (ex. readlog()) in source code,
> nm smtplog | grep readlog or
> objdump -tD smtplog | grep readlog
> result is nothing means this symbol is not present in binary.

Is the binary stripped? What does 'file smtplog' say?

What are the compile and link lines for the binary?

I have seen "unintentional" stripping of the binaries when link
commands are "mindlessly" copied from one platform to another.

For example, 'gcc main.c -s -o smtplog' will produce a stripped
binary on Linux and Solaris (because gcc will pass '-s' to the
linker), but perhaps '-s' means something else to another compiler,
for which the command line was originally written.

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

gunvant.k.patil@gmail.com

2007-03-30, 7:17 am

On Mar 29, 12:28 pm, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
wrote:
> "gunvant.k.pa...@gmail.com" <gunvant.k.pa...@gmail.com> writes:
>
> Is the binary stripped? What does 'file smtplog' say?

[root@osqa61 bin]# file smtplog
smtplog: setuid ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.2.5, statically linked, not stripped

> What are the compile and link lines for the binary?

gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -c /usr/home/gpatil/mirasrc/
fling/src/mira/usr.bin/smtplog/main.c
gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -c /usr/home/gpatil/mirasrc/
fling/src/mira/usr.bin/smtplog/stack.c
gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -c /usr/home/gpatil/mirasrc/
fling/src/mira/usr.bin/smtplog/summary.c
gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -c /usr/home/gpatil/mirasrc/
fling/src/mira/usr.bin/smtplog/detail.c
gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -c /usr/home/gpatil/mirasrc/
fling/src/mira/usr.bin/smtplog/dump.c
gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -c /usr/home/gpatil/mirasrc/
fling/src/mira/usr.bin/smtplog/histogram.c
gcc -O -pipe -march=pentiumpro -DMIRA_LINUX=1 -D_GNU_SOURCE=1 -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -imacros /usr/home/gpatil/
mirasrc/fling/src/mira/include/pal/syscall_remap.h -O2 -Wall -
Wimplicit -Werror -g -I/usr/home/gpatil/mirasrc/fling/src/mira/usr.bin/
smtplog/../../lib/libi18n -I/usr/home/gpatil/mirasrc/fling/src/mira/
usr.bin/smtplog/../../lib/libmappsupport -static -o smtplog main.o
stack.o summary.o detail.o dump.o histogram.o -larchive -lnewcgi -
lmappsupport -lmira -lpal -lvdb -lcharset -li18n -lz -lstdc++ -
lpthread
/usr/home/gpatil/mirasrc/fling/obj/mira/lib/distrib/
libmira.a(mira_util.o)(.text+0x3a9): In function `mira_seteuid':
/usr/home/gpatil/mirasrc/fling/src/mira/lib/libmira/mira_util.c:320:
warning: Using 'getpwnam' in statically linked applications requires
at runtime the shared libraries from the glibc version used for
linking
/usr/home/gpatil/mirasrc/fling/obj/mira/lib/distrib/
libmira.a(idmatch.o)(.text+0x500): In function `hostaddr':
/usr/home/gpatil/mirasrc/fling/src/mira/lib/libmira/../libgulp/
idmatch.c:298: warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking

> I have seen "unintentional" stripping of the binaries when link
> commands are "mindlessly" copied from one platform to another.
>
> For example, 'gcc main.c -s -o smtplog' will produce a stripped
> binary on Linux and Solaris (because gcc will pass '-s' to the
> linker), but perhaps '-s' means something else to another compiler,
> for which the command line was originally written.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

Paul Pluzhnikov

2007-03-30, 7:19 pm

"gunvant.k.patil@gmail.com" <gunvant.k.patil@gmail.com> writes:

> gcc -O -pipe -march=pentiumpro -D... -O2 -Wall -Wimplicit -Werror -g -I ...

Hmm, gcc-3.4.6 doesn't appear to inline functions with with the
command line above, but perhaps your gcc does? Try compiling with
-fno-inline-functions ...

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