Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

GCC: linking the project in DEBUG cfg to debug GLIBC

Posted on 2011-03-14
31
Medium Priority
?
801 Views
Last Modified: 2012-05-11
Hi, guys!

I've installed glibc-debuginfo, glibc-debuginfo-common, gcc-debuginfo packages under CentOS 5.5 to be able to step into default libs in the debugger. RPM installed libs (static and dynamic) into separate folder /usr/lib.debug/lib and, also, installed source code into /usr/src/debug.

In contrast to release libs the debug libs have ".debug" file extension. Now I need to link to them in DEBUG build configuration. I added -L switch:

COMPILE=g++ -c  "-D_GLIBCXX_DEBUG" -g -O0 -fno-inline -o "$(OUTDIR)/$(*F).o" $(CFG_INC) $<
LINK=g++  -g -L/usr/lib/debug/usr/lib -o "$(OUTFILE)" $(ALL_OBJ)

After that, GCC started to link to debug libs and I'm able to step into them (for instance, into wprintf).

But, had executed LDD I was surprised:

ldd Hello
        linux-gate.so.1 =>  (0x00ec9000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x02839000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x02702000)
        libm.so.6 => /lib/libm.so.6 (0x00bb1000)
        libc.so.6 => /lib/libc.so.6 (0x00381000)
        /lib/ld-linux.so.2 (0x00e69000)

It shows, that my program is linked to release libs, not to debug ones! But, nevertheless, with -L/usr/lib/debug/usr/lib option I'm able to step into. So, indeed, my program is linked to debug ones.

Q1. Why LDD shows release libs in dependence list?
Q2. During debugging GDB asks me to point where each source code file is. Could I specify the source code directory  in environment variable or somethere else?

0
Comment
Question by:Alexey Fedorov
  • 14
  • 10
  • 7
31 Comments
 
LVL 8

Expert Comment

by:ssnkumar
ID: 35133991
When you execute your program, it checks for the libraries in standard path.
The libs you have linked have the same name in both standard path and debug path.
And it finds the libs in the standard path first and uses it.
If you want to link to the libs in the debug path, use the LD_LIBRARY_PATH.
export LD_LIBRARY_PATH=/usr/lib/debug/usr/lib:$LD_LIBRARY_PATH
And execute "ldd Hello" now.
This should link you to the debug libraries instead of standard libraries.
0
 

Author Comment

by:Alexey Fedorov
ID: 35136129
Thanks, ssnkumar!

Libs don't have the same file names. Let us consider libc.so.6. I searched through all the drive:

/usr/lib
     libc.so
/usr/lib/debug/lib
     libc.so.6.debug
/usr/lib/debug/lib/i686/nosegneg
     libc.so.6.debug
/lib
     libc.so.6
/lib/i686/nosegneg
     libc.so.6

As you can see there are two of them: libc.so.6 and libc.so.6.debug. Maybe, you keep in mind GCC library naming convention? According to the convention: the lib's name in "c".

Anyway, I still don't understand the right way of working with dbug libs in Linux. If I set LD_LIBRARY_PATH to point to debug libs firstly, than all the applications will load debug libs. Isn't it?

I can explain how does it work in Windows with Visual Studio C++ projects. It's quite straightforwardly.
On WIndows for a WIn32 C++ console app in Visual Studio 2010 it looks as follow.
  dumpbin /dependents shows:
     KERNEL32.dll
     MSVCR100.dll for release build, and

     KERNEL32.dll
     MSVCR100D.dll for debu build

Both MSVCR100 are located in Windows/System32. So, only the applications which you are debugging at the moment a linked to debug MSVCR100. Also, MSVCR100's source code resides in VS direcory and VS debugger is able to step into. It's very handy and easy to use.

0
 
LVL 35

Assisted Solution

by:Duncan Roe
Duncan Roe earned 860 total points
ID: 35136534
The system library libc.so is more complex than it might at first appear. Look at the output from ls -l /usr/lib/libc.so. You will find it is not a symbolic link, rather it is an ld script. Mine looks like:
21:08:59$ cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.2 ) )

Open in new window

Possibly yours is different now owing to the installation of debuginfo - please post it if so.
0
Learn Veeam advantages over legacy backup

Every day, more and more legacy backup customers switch to Veeam. Technologies designed for the client-server era cannot restore any IT service running in the hybrid cloud within seconds. Learn top Veeam advantages over legacy backup and get Veeam for the price of your renewal

 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35136588
I think it would be interesting for you, and helpful for us experts, if you could post the output from locate libc|grep -w libc|egrep -v '^/usr/(share|local|info|man)'|xargs ls -l
You might need to extend the egrep to exclude other non-library clutter. On my system:
21:12:48$ locate libc|grep -w libc|egrep -v '^/(fedora64|linux64|oldsys|home|not|usr/(share|local|info|gz|man))'|xargs ls -l
-rwxr-xr-x 1 root root 1724083 Mar  7  2010 /lib/libc-2.10.1.so
-rwxr-xr-x 1 root root 1649149 May 13  2010 /lib/libc-2.11.1.so
-rwxr-xr-x 1 root root 1458907 May 19  2003 /lib/libc-2.3.2.so
-rwxr-xr-x 1 root root 1528742 Jun 20  2007 /lib/libc-2.5.so
-rwxr-xr-x 1 root root 1570593 Nov 21  2008 /lib/libc-2.7.so
-rwxr-xr-x 1 root root 1658350 Apr  3  2009 /lib/libc-2.9.so
lrwxrwxrwx 1 root root      13 Sep 30  2004 /lib/libc.so.4 -> libc.so.4.7.2
-rwxr-xr-x 1 root root  634880 Apr 30  1995 /lib/libc.so.4.7.2
lrwxrwxrwx 1 root root      14 Sep 30  2004 /lib/libc.so.5 -> libc.so.5.4.44
-rwxr-xr-x 1 root root 2178190 Feb 22  1998 /lib/libc.so.5.4.44
lrwxrwxrwx 1 root root      14 Jul 25  2010 /lib/libc.so.6 -> libc-2.11.1.so
-rw-r--r-- 1 root root   21508 May 13  2010 /usr/include/bits/libc-lock.h
-rw-r--r-- 1 root root    1337 May 13  2010 /usr/include/gnu/libc-version.h
-rw-r--r-- 1 root root 3154784 May 13  2010 /usr/lib/libc.a
-rw-r--r-- 1 root root     238 May 13  2010 /usr/lib/libc.so

Open in new window

(The last time I did a complete re-install rather than upgrade was in 1994. So I have rather a lot of old libraries).
The setup of the debug libraries on your system should be interesting.
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35136647
By the way, your LINK line looks wrong to me:
LINK=g++  -g -L/usr/lib/debug/usr/lib -o "$(OUTFILE)" $(ALL_OBJ)
You did not mention /usr/lib/debug/usr/lib in http:#a35136129, only /usr/lib/debug/lib. Maybe ldd will work as you want if you would fix that.
If not, there are many other possibilities I can think of. Let us know how you go
0
 

Author Comment

by:Alexey Fedorov
ID: 35136757
Duncan, I don't have "locate" installed. What package I need?
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35136802
locate comes from the findutils package. But you might have slocate from the slocate package - try that.
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35136822
Corection: locate is the old name (symbolic link on my system). Now there is only slocate
0
 

Author Comment

by:Alexey Fedorov
ID: 35136862
There is no "slocate: in findutils package:

rpm -ql findutils
/usr/bin/find
/usr/bin/xargs
/usr/share/doc/findutils-4.2.27
/usr/share/doc/findutils-4.2.27/AUTHORS
/usr/share/doc/findutils-4.2.27/COPYING
/usr/share/doc/findutils-4.2.27/NEWS
/usr/share/doc/findutils-4.2.27/README
/usr/share/doc/findutils-4.2.27/THANKS
/usr/share/doc/findutils-4.2.27/TODO
/usr/share/info/find.info.gz
/usr/share/locale/be/LC_MESSAGES/findutils.mo
/usr/share/locale/ca/LC_MESSAGES/findutils.mo
/usr/share/locale/da/LC_MESSAGES/findutils.mo
/usr/share/locale/de/LC_MESSAGES/findutils.mo
/usr/share/locale/el/LC_MESSAGES/findutils.mo
/usr/share/locale/eo/LC_MESSAGES/findutils.mo
/usr/share/locale/es/LC_MESSAGES/findutils.mo
/usr/share/locale/et/LC_MESSAGES/findutils.mo
/usr/share/locale/fi/LC_MESSAGES/findutils.mo
/usr/share/locale/fr/LC_MESSAGES/findutils.mo
/usr/share/locale/ga/LC_MESSAGES/findutils.mo
/usr/share/locale/gl/LC_MESSAGES/findutils.mo
/usr/share/locale/hr/LC_MESSAGES/findutils.mo
/usr/share/locale/hu/LC_MESSAGES/findutils.mo
/usr/share/locale/id/LC_MESSAGES/findutils.mo
/usr/share/locale/it/LC_MESSAGES/findutils.mo
/usr/share/locale/ja/LC_MESSAGES/findutils.mo
/usr/share/locale/ko/LC_MESSAGES/findutils.mo
/usr/share/locale/lg/LC_MESSAGES/findutils.mo
/usr/share/locale/ms/LC_MESSAGES/findutils.mo
/usr/share/locale/nl/LC_MESSAGES/findutils.mo
/usr/share/locale/pl/LC_MESSAGES/findutils.mo
/usr/share/locale/pt/LC_MESSAGES/findutils.mo
/usr/share/locale/pt_BR/LC_MESSAGES/findutils.mo
/usr/share/locale/ro/LC_MESSAGES/findutils.mo
/usr/share/locale/ru/LC_MESSAGES/findutils.mo
/usr/share/locale/rw/LC_MESSAGES/findutils.mo
/usr/share/locale/sk/LC_MESSAGES/findutils.mo
/usr/share/locale/sl/LC_MESSAGES/findutils.mo
/usr/share/locale/sr/LC_MESSAGES/findutils.mo
/usr/share/locale/sv/LC_MESSAGES/findutils.mo
/usr/share/locale/tr/LC_MESSAGES/findutils.mo
/usr/share/locale/vi/LC_MESSAGES/findutils.mo
/usr/share/locale/zh_CN/LC_MESSAGES/findutils.mo
/usr/share/locale/zh_TW/LC_MESSAGES/findutils.mo
/usr/share/man/man1/find.1.gz
/usr/share/man/man1/xargs.1.gz

Open in new window

0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35136896
Sorry no. slocate comes in slocate package - findutils was my mistake. Don't you have slocate?
At least in Slackware it comes in slocate package - in RedHat / CentOS they may have called it something else.
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 35138026
> As you can see there are two of them: libc.so.6 and libc.so.6.debug.
That is correct.
But, these files are not accessed directly.
You will have libc.so file which will be a soft link to libc.so.6.
In the same way, there must be a link libc.so which links to libc.so.6.debug.
You can use find command to check all the libc.so files on your system:
find / -name "libc.so*" | xargs ls -l

If there is no libc.so linking to libc.so.6.debug, then you should create this link.
But, make sure that this new libc.so link comes first before the one in the /lib.
For this, you can use LD_LIBRARY_PATH as I mentioned before.

Try it and let me know the outcome.
0
 

Author Comment

by:Alexey Fedorov
ID: 35141125
I installed "locate", but it fails:

locate: can not open `/var/lib/mlocate/mlocate.db': No such file or directory
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35142399
@ssnkumar: libc.so is not a synbolic link as per my post http:#a35136534. Please read preceding posts before posting yourself
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35142443
@alexf2: The locate system needs you to have run the database updater at least once before it can work. Usually the package will install this as a cron job to be run daily - look for the file /etc/cron.daily/slocate, /etc/cron.daily/slocate.cron or maybe something similar. You can invoke it as root manually to set up the initial database
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 35143175
duncan_roe>  libc.so is not a synbolic link as per my post http:#a35136534.
I don't know on which system you don't see libc.so to be a regular file instead of a soft link.
For example, on my Solaris box, I see this:
ls -l /usr/lib/libc.so
lrwxrwxrwx 1 root root 19 2011-03-15 22:37 /usr/lib/libc.so -> ../../lib/libc.so.1

duncan_roe> Please read preceding posts before posting yourself
So, you don't have to be very harsh for others.
There are so many different versions of Linux and Unix out here.
Something you are thinking as a fact could not be true for all the systems!
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 35144973
So, what is the o/p of:
LD_LIBRARY_PATH=/usr/lib/debug/usr/lib ldd Hello

And can you try to link libc.so to /usr/lib/debug/usr/lib/libc.so.6.debug
and execute ldd hello?
But, don't create libc.so under /libr or /usr/lib.
Create it under some other directory, say /tmp.
And then try the command:
LD_LIBRARY_PATH=/tmp ldd Hello
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35145974
ssnkumar> sorry I was concerned not to confuse the author of the question. Solaris does not use glibc - glibc is only ported to Linux and variants like Cygwin. glibc always has /usr/lib/libc.so as an ld script regardless of Linux distribution.
0
 

Author Comment

by:Alexey Fedorov
ID: 35146538
I executed "locate":
 locate libc|grep -w libc|egrep -v '^/usr/(share|local|info|man)'|xargs ls -l

-rwxr-xr-x 1 root root  1702572 ¿¿¿ 26 03:16 /lib/i686/nosegneg/libc-2.5.so
lrwxrwxrwx 1 root root       11 ¿¿¿ 14 16:51 /lib/i686/nosegneg/libc.so.6 -> libc-2.5.so
-rwxr-xr-x 1 root root  1689640 ¿¿¿ 26 03:16 /lib/libc-2.5.so
lrwxrwxrwx 1 root root       11 ¿¿¿ 14 16:51 /lib/libc.so.6 -> libc-2.5.so
-rw-r--r-- 1 root root    12844 ¿¿¿  3  2006 /usr/include/bits/libc-lock.h
-rw-r--r-- 1 root root     1337 ¿¿¿ 26 00:06 /usr/include/gnu/libc-version.h
-rwxr-xr-x 1 root root  5559984 ¿¿¿ 26 03:16 /usr/lib/debug/lib/i686/nosegneg/libc-2.5.so.debug
lrwxrwxrwx 1 root root       17 ¿¿¿ 14 18:56 /usr/lib/debug/lib/i686/nosegneg/libc.so.6.debug -> libc-2.5.so.debug
-rwxr-xr-x 1 root root  5556784 ¿¿¿ 26 03:16 /usr/lib/debug/lib/libc-2.5.so.debug
lrwxrwxrwx 1 root root       17 ¿¿¿ 14 18:56 /usr/lib/debug/lib/libc.so.6.debug -> libc-2.5.so.debug
-rw-r--r-- 1 root root 12960864 ¿¿¿ 26 00:05 /usr/lib/debug/usr/lib/libc.a
-rw-r--r-- 1 root root  3011050 ¿¿¿ 26 00:40 /usr/lib/libc.a
-rw-r--r-- 1 root root      238 ¿¿¿ 26 00:06 /usr/lib/libc.so
-rw-r--r-- 1 root root     8008 ¿¿¿ 14  2005 /usr/src/debug/glibc-2.5-20061008T1257/csu/libc-start.c
-rw-r--r-- 1 root root     6603 ¿¿¿ 12  2005 /usr/src/debug/glibc-2.5-20061008T1257/elf/dl-libc.c
-rw-r--r-- 1 root root     3074 ¿¿¿ 22  2005 /usr/src/debug/glibc-2.5-20061008T1257/nptl/libc-cancellation.c
-rw-r--r-- 1 root root    21235 ¿¿¿ 26 02:05 /usr/src/debug/glibc-2.5-20061008T1257/nptl/sysdeps/pthread/bits/libc-lock.h

Open in new window


0
 
LVL 8

Assisted Solution

by:ssnkumar
ssnkumar earned 140 total points
ID: 35146705
From the above o/p, I see your debug libraries at:
/usr/lib/debug/lib/i686/nosegneg/libc-2.5.so.debug
/usr/lib/debug/lib/i686/nosegneg/libc.so.6.debug -> libc-2.5.so.debug
/usr/lib/debug/lib/libc-2.5.so.debug
/usr/lib/debug/lib/libc.so.6.debug -> libc-2.5.so.debug
/usr/lib/debug/usr/lib/libc.a

And you are linking using the command:
g++  -g -L/usr/lib/debug/usr/lib -o "$(OUTFILE)" $(ALL_OBJ)

Here you are using /usr/lib/debug/usr/lib with -L flag.
At this location, you have the static library: /usr/lib/debug/usr/lib/libc.a
So, your static library got compiled along with your source.
And because of this, you are not seeing the debug library when you did "ldd hello".

So, if you want to link to the dynamic library instead of static library, you have to change the linker command to:
g++  -g -L/usr/lib/debug/lib -o "$(OUTFILE)" $(ALL_OBJ)

Even if you do this, you will need to use LD_LIBRARY_PATH when you either execute the code or do ldd:
LD_LIBRARY_PATH=/usr/lib/debug/lib ldd hello
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35146734
/usr/lib/libc.so is a regular file. At 238 bytes, it is the same size as on my system, so probably it is the standard one (not loading the debug libraries). but you could cat it to check.
But you say you can now step into glibc. I see - you have a /usr/lib/debug/usr/lib/libc.a. That must be what you are loading, because there is no /usr/lib/debug/usr/lib/libc.so. You could make one, if you have /usr/lib/debug/usr/lib/libc_nonshared.a - do you have that file?
Actually please post the output from ls -l /usr/lib/debug/usr/lib
0
 

Author Comment

by:Alexey Fedorov
ID: 35146744
OK, ssnkumar!
Does setting LD_LIBRARY_PATH affect all the applications?
0
 

Author Comment

by:Alexey Fedorov
ID: 35146753
ls -l /usr/lib/debug/usr/lib

drwxr-xr-x 2 root root    12288 ¿¿¿ 14 18:56 gconv
-rw-r--r-- 1 root root    81888 ¿¿¿ 26 00:07 libanl.a
-rw-r--r-- 1 root root     3612 ¿¿¿ 26 00:06 libBrokenLocale.a
lrwxrwxrwx 1 root root       15 ¿¿¿ 14 18:56 libbsd.a -> libbsd-compat.a
-rw-r--r-- 1 root root     2398 ¿¿¿ 26 00:06 libbsd-compat.a
-rw-r--r-- 1 root root 12960864 ¿¿¿ 26 00:05 libc.a
-rw-r--r-- 1 root root    53230 ¿¿¿ 26 00:05 libc_nonshared.a
-rw-r--r-- 1 root root   149588 ¿¿¿ 26 00:07 libcrypt.a
-rw-r--r-- 1 root root     9716 ¿¿¿ 26 00:07 libc_stubs.a
-rw-r--r-- 1 root root    32298 ¿¿¿ 26 00:06 libdl.a
-rw-r--r-- 1 root root     2398 ¿¿¿ 26 00:06 libg.a
-rwxr-xr-x 1 root root     1052 ¿¿¿ 14  2010 libgcj_bc.so.1.0.0.debug
lrwxrwxrwx 1 root root       24 ¿¿¿ 14 18:57 libgcj_bc.so.1.debug -> libgcj_bc.so.1.0.0.debug
-rwxr-xr-x 1 root root 33204240 ¿¿¿ 14  2010 libgcj.so.7rh.0.0.debug
lrwxrwxrwx 1 root root       23 ¿¿¿ 14 18:57 libgcj.so.7rh.debug -> libgcj.so.7rh.0.0.debug
lrwxrwxrwx 1 root root       23 ¿¿¿ 14 18:57 libgcj.so.debug -> libgcj.so.7rh.0.0.debug
-rwxr-xr-x 1 root root   938348 ¿¿¿ 14  2010 libgcj-tools.so.7rh.0.0.debug
lrwxrwxrwx 1 root root       29 ¿¿¿ 14 18:57 libgcj-tools.so.7rh.debug -> libgcj-tools.so.7rh.0.0.debug
lrwxrwxrwx 1 root root       29 ¿¿¿ 14 18:57 libgcj-tools.so.debug -> libgcj-tools.so.7rh.0.0.debug
-rwxr-xr-x 1 root root  1281876 ¿¿¿ 14  2010 libgfortran.so.1.0.0.debug
lrwxrwxrwx 1 root root       26 ¿¿¿ 14 18:57 libgfortran.so.1.debug -> libgfortran.so.1.0.0.debug
lrwxrwxrwx 1 root root       26 ¿¿¿ 14 18:57 libgfortran.so.debug -> libgfortran.so.1.0.0.debug
-rwxr-xr-x 1 root root    10848 ¿¿¿ 14  2010 libgij.so.7rh.0.0.debug
lrwxrwxrwx 1 root root       23 ¿¿¿ 14 18:57 libgij.so.7rh.debug -> libgij.so.7rh.0.0.debug
lrwxrwxrwx 1 root root       23 ¿¿¿ 14 18:57 libgij.so.debug -> libgij.so.7rh.0.0.debug
-rwxr-xr-x 1 root root   379128 ¿¿¿ 14  2010 libgnarl-4.1.so.debug
-rwxr-xr-x 1 root root  3422652 ¿¿¿ 14  2010 libgnat-4.1.so.debug
-rw-r--r-- 1 root root     1796 ¿¿¿ 26 00:06 libieee.a
-rw-r--r-- 1 root root  1241778 ¿¿¿ 26 00:06 libm.a
-rw-r--r-- 1 root root     2940 ¿¿¿ 26 00:06 libmcheck.a
-rwxr-xr-x 1 root root    22588 ¿¿¿ 26 00:39 libmemusage.so.debug
-rwxr-xr-x 1 root root   142872 ¿¿¿ 14  2010 libmudflap.so.0.0.0.debug
lrwxrwxrwx 1 root root       25 ¿¿¿ 14 18:57 libmudflap.so.0.debug -> libmudflap.so.0.0.0.debug
lrwxrwxrwx 1 root root       25 ¿¿¿ 14 18:57 libmudflap.so.debug -> libmudflap.so.0.0.0.debug
-rwxr-xr-x 1 root root   151992 ¿¿¿ 14  2010 libmudflapth.so.0.0.0.debug
lrwxrwxrwx 1 root root       27 ¿¿¿ 14 18:57 libmudflapth.so.0.debug -> libmudflapth.so.0.0.0.debug
lrwxrwxrwx 1 root root       27 ¿¿¿ 14 18:57 libmudflapth.so.debug -> libmudflapth.so.0.0.0.debug
-rw-r--r-- 1 root root   756082 ¿¿¿ 26 00:07 libnsl.a
-rwxr-xr-x 1 root root   226996 ¿¿¿ 14  2010 libobjc.so.1.0.0.debug
lrwxrwxrwx 1 root root       22 ¿¿¿ 14 18:57 libobjc.so.1.debug -> libobjc.so.1.0.0.debug
lrwxrwxrwx 1 root root       22 ¿¿¿ 14 18:57 libobjc.so.debug -> libobjc.so.1.0.0.debug
-rwxr-xr-x 1 root root     6916 ¿¿¿ 26 00:39 libpcprofile.so.debug
-rw-r--r-- 1 root root  1069116 ¿¿¿ 26 00:07 libpthread.a
-rw-r--r-- 1 root root     3532 ¿¿¿ 26 00:07 libpthread_nonshared.a
-rw-r--r-- 1 root root   355468 ¿¿¿ 26 00:07 libresolv.a
-rw-r--r-- 1 root root   230788 ¿¿¿ 26 00:07 librpcsvc.a
-rw-r--r-- 1 root root   232300 ¿¿¿ 26 00:07 librt.a
-rw-r--r-- 1 root root   261318 ¿¿¿ 26 00:07 librtkaio.a
-rwxr-xr-x 1 root root  3498848 ¿¿¿ 14  2010 libstdc++.so.6.0.8.debug
lrwxrwxrwx 1 root root       24 ¿¿¿ 14 18:57 libstdc++.so.6.debug -> libstdc++.so.6.0.8.debug
lrwxrwxrwx 1 root root       24 ¿¿¿ 14 18:57 libstdc++.so.debug -> libstdc++.so.6.0.8.debug
-rw-r--r-- 1 root root    28268 ¿¿¿ 26 00:07 libutil.a

Open in new window

0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 35146776
> Does setting LD_LIBRARY_PATH affect all the applications?
If you do:
export LD_LIBRARY_PATH
after adding the new path, that will have effect on all the applications.

But, if you are using it in the way I mentioned before:
LD_LIBRARY_PATH=/usr/lib/debug/lib ldd hello

that will affect only the command that you are running now (that is ldd in the above example).
0
 
LVL 8

Expert Comment

by:ssnkumar
ID: 35146785
But, for getting your code compiled with dynamic libraries and seeing those libs later while doing ldd, you will have to compile using:
g++  -g -L/usr/lib/debug/lib -o "$(OUTFILE)" $(ALL_OBJ)

Note that, I have changed the library path in the above g++ command.
0
 
LVL 35

Accepted Solution

by:
Duncan Roe earned 860 total points
ID: 35152244
I think you need to do the following in preparation for a dynamic debug load:

cd /usr/lib/debug/usr/lib
ln -s libstdc++.so.6.0.8.debug libstdc++.so
echo 'OUTPUT_FORMAT(elf32-i386)' >libc.so
echo 'GROUP ( /usr/lib/debug/lib/libc.so.6.debug /usr/lib/debug/usr/lib/libc_nonshared.a  AS_NEEDED (  /usr/lib/debug/lib/ld-linux.so.2.debug  ) )' >>libc.so

Open in new window


Also extend you build line:

LINK=g++  -g -L/usr/lib/debug/usr/lib -o "$(OUTFILE)" $(ALL_OBJ) -Wl,-rpath,/usr/lib/debug/lib

 -Wl should obviate need to mess about with LD_LIBRARY_PATH.
Have to go now.
0
 

Assisted Solution

by:Alexey Fedorov
Alexey Fedorov earned 0 total points
ID: 35171724
Hi, guys!

Tried
 -L/usr/lib/debug/usr/lib
 -L/usr/lib/debug/lib

-Wl,-rpath,/usr/lib/debug/lib

Setting LD_LIBRARY_PATH to /usr/lib/debug/lib
Nothing helped.

Adding -L/usr/lib/debug/usr/lib works fine only with -static. Withot -static it produces executable linked to release libs, but the debugger starts to step into libs and at the end the program crushes with segmentation fault in "exit" function.
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35173858
That's to be expected because there are no .so files in /usr/lib/debug/usr/lib. Maybe another RPM would supply these (you need all of them, not just libc) - I'll have a look.
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35174024
I downloaded and tried to use the debuginfo RPMs. Specifically I installed glibc-debuginfo-common-2.5-49.el5_5.7.i386.rpm, glibc-debuginfo-2.5-49.el5_5.7.i386.rpm and gcc-debuginfo-4.1.2-46.el5_4.2.i386.rpm.
As far as I can see, the dynamic objects don't work. Have you tried running any of the programs in /usr/lib/debug/usr/bin? For me, they all give the error No such file or directory (that's the confusing error you get when the dynamic loader that is hard-coded into an ELF program is not found).
0
 
LVL 35

Expert Comment

by:Duncan Roe
ID: 35174032
(Didn't really mean to finish there). I am not able to load symbols from the supplied debuginfo.so libraries either - dlopen() gets a seg fault.
Possibly there is documentation somewhere of special measures required to use the debuginfo system, but I can't find any.
-static debug is fine - I suggest you stick to that.
0
 

Author Comment

by:Alexey Fedorov
ID: 35358592
Thanks guys!
Excuse me for a delay: I had too much Windows-work :-), so I had to switch out.

We are ending up with the static build as the straight forward one.
Thank you for the explanations!

Good luck!
0
 

Author Closing Comment

by:Alexey Fedorov
ID: 35390623
The final soulution us a workaround.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

IntroductionThis article is the second in a three part article series on the Visual Studio 2008 Debugger.  It provides tips in setting and using breakpoints. If not familiar with this debugger, you can find a basic introduction in the EE article loc…
C++ Properties One feature missing from standard C++ that you will find in many other Object Oriented Programming languages is something called a Property (http://www.experts-exchange.com/Programming/Languages/CPP/A_3912-Object-Properties-in-C.ht…
The goal of this video is to provide viewers with basic examples to understand recursion in the C programming language.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

885 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question