"ld" and "QCC" hang trying to link valid object file

bridged with qdn.public.qnxrtp.devtools
Shouqin Huo

Re: "ld" and "QCC" hang trying to link valid object file

Post by Shouqin Huo » Wed Feb 12, 2003 6:39 pm

Thanks. This is very significant information for me. By turning off the
debug flag, I was able to quickly resolve the problem that has been bugging
me for weeks.

I have had the debug flag on before. Without any error messages, I had to
do binary search to find the class that was causing the problem. I got the
code to compile by excluding one class, but still did not know why. Now with
the debug flag off, I found that there was one undefined function in it. I
fixed it and it compiles happily with or without the debug flag.

Does anyone from QSSL want to comment on this? When can we expect a fix to
the problem?

Shouqin Huo
Quantum Magnetics
"John Nagle" <nagle@downside.com> wrote in message
news:3E49F10E.7090503@downside.com...
Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc

to generate debug info. You'll get a junk "a.out" file,
with no error messages. So this problem is somehow
involved with the generation of debug information.

The recursive build system adds quite a few options to
the qcc command line, so it's better to try this with
a cleaner situation.

John Nagle
Animats

Chris McKillop wrote:
John Nagle <nagle@downside.com> wrote:

Any word on this? I'm currently programming by using
"nm" to read out all the undefined symbols and checking
them by hand when the QNX "ld" fails. This is becoming
somewhat annoying.

If it's the Free Software Foundation's problem, let
me know, and I'll bug one of the GNU developers. I'm
still not clear on whether QSSL or FSF maintains the
QNX "ld". Thanks.



I just tried your code on a 6.2.0 PE, 6.2.1 PE and 6.2.0 NC. Now, I am
using our recursive build system, you can get the sources here:

http://qnx.wox.org/nagle.tar.gz

In all cases it compiles fine and fails to link. Gives proper warning
about
the lack of the missing function. If you get that tarball and run make
does it behave for you?

chris

Chris McKillop

Re: "ld" and "QCC" hang trying to link valid object file

Post by Chris McKillop » Wed Feb 12, 2003 9:45 pm

Does anyone from QSSL want to comment on this? When can we expect a fix to
the problem?
I think I already did. ;)

chris


--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Colin Burgess

Re: "ld" and "QCC" hang trying to link valid object file

Post by Colin Burgess » Thu Feb 13, 2003 2:25 pm

Between 6.2.0 and 6.2.1 the default debug format changed from Dwarf to Stabs+,
although this suceeds for me on 6.2.1 with -gdwarf.

I do remember fixing an ld bug wrt dwarf1 undefined references a LONG time
ago though, it should have been in 6.2.0

In any case, I'd recommend -gstabs+ to any C++ developers using 6.2.0 - it's
simply a lot better for C++ than DWARF1.

Chris McKillop <cdm@qnx.com> wrote:
John Nagle <nagle@downside.com> wrote:
Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc


Okie dokie - there is a bug in the qcc conf files on 6.2.0 when using
the gcc_ntox86_gpp target (the default for QCC on NC). On a PE machine
under 6.2.0 I can reproduce this bug using:

QCC -Vgcc_ntox86_gpp -g main.cc

However, on 6.2.1 this has been fixed (tested both GNU and Dinkum targets).

This doesn't appear to happen (on 6.2.0) when you use all the options provided
by the recursive make system for a debug target. You can try that out by
invoking "addvariant x86 o.g" and running make in x86/o.g.
chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/


--
cburgess@qnx.com

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Thu Feb 13, 2003 7:38 pm

OK, tried that. The "recursive build system" then
introduced a call to "usemsg", which complained
"Bad format for load module" when processing the .o
file generated with -g enabled. See below. That's
another indication that compiling with -g is producing
bad .o files.

Adding the options introduced by the "recursive build system"
does not seem to affect the problem. It's the presence or
absence of "-g" that does it.

Is there some way to get debug info without bad object files?
If this is fixed in 6.2.1, is there a downloadable upgrade
for the NC version?

John Nagle
Animats

$ addvariant x86 o.g
Creating /home/public/nagle/x86/o.g directory...
$ make
make -j 1 -Cx86 -fMakefile
make[1]: Entering directory `/home/public/nagle/x86'
make -j 1 -Co -fMakefile && make -j 1 -Co.g -fMakefile
make[2]: Entering directory `/home/public/nagle/x86/o'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/public/nagle/x86/o'
make[2]: Entering directory `/home/public/nagle/x86/o.g'
/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -I. -I/home/public/nagle/x86/o -I/home/public/nagle/x86/o.g -I/home/public/nagle/x86 -I/home/public/nagle -I/usr/include -g -DVARIANT_g /home/public/nagle/main.cc
/bin/rm -f /home/public/nagle/x86/o.g/nagle_g
/usr/bin/qcc -Vgcc_ntox86 -lang-c++ -o/home/public/nagle/x86/o.g/nagle_g main.o -L. -L/x86/lib -L/x86/usr/lib -g
/usr/bin/usemsg -s __USAGENTO -s __USAGE /home/public/nagle/x86/o.g/nagle_g /home/public/nagle/nagle.use
Bad format for load module /home/public/nagle/x86/o.g/nagle_g.
make[2]: *** [/home/public/nagle/x86/o.g/nagle_g] Error 1
make[2]: Leaving directory `/home/public/nagle/x86/o.g'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/public/nagle/x86'
make: *** [all] Error 2

Chris McKillop wrote:
John Nagle <nagle@downside.com> wrote:

Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc



Okie dokie - there is a bug in the qcc conf files on 6.2.0 when using
the gcc_ntox86_gpp target (the default for QCC on NC). On a PE machine
under 6.2.0 I can reproduce this bug using:

QCC -Vgcc_ntox86_gpp -g main.cc

However, on 6.2.1 this has been fixed (tested both GNU and Dinkum targets).

This doesn't appear to happen (on 6.2.0) when you use all the options provided
by the recursive make system for a debug target. You can try that out by
invoking "addvariant x86 o.g" and running make in x86/o.g.


chris
Chris McKillop wrote:
John Nagle <nagle@downside.com> wrote:

Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc



Okie dokie - there is a bug in the qcc conf files on 6.2.0 when using
the gcc_ntox86_gpp target (the default for QCC on NC). On a PE machine
under 6.2.0 I can reproduce this bug using:

QCC -Vgcc_ntox86_gpp -g main.cc

However, on 6.2.1 this has been fixed (tested both GNU and Dinkum targets).

This doesn't appear to happen (on 6.2.0) when you use all the options provided
by the recursive make system for a debug target. You can try that out by
invoking "addvariant x86 o.g" and running make in x86/o.g.


chris

Colin Burgess

Re: "ld" and "QCC" hang trying to link valid object file

Post by Colin Burgess » Fri Feb 14, 2003 3:02 pm

There was a bug fixed in dwarf1 handling between 6.2.0 and 6.2.1, however
I think that in this case it might not be that one.

I think that nagle_g in this case is probably a corrupt file, and that
ld is crashing somehow. What does file nagle_g say?

Did you try the -gstabs+?

John Nagle <nagle@downside.com> wrote:
OK, tried that. The "recursive build system" then
introduced a call to "usemsg", which complained
"Bad format for load module" when processing the .o
file generated with -g enabled. See below. That's
another indication that compiling with -g is producing
bad .o files.

Adding the options introduced by the "recursive build system"
does not seem to affect the problem. It's the presence or
absence of "-g" that does it.

Is there some way to get debug info without bad object files?
If this is fixed in 6.2.1, is there a downloadable upgrade
for the NC version?

John Nagle
Animats

$ addvariant x86 o.g
Creating /home/public/nagle/x86/o.g directory...
$ make
make -j 1 -Cx86 -fMakefile
make[1]: Entering directory `/home/public/nagle/x86'
make -j 1 -Co -fMakefile && make -j 1 -Co.g -fMakefile
make[2]: Entering directory `/home/public/nagle/x86/o'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/public/nagle/x86/o'
make[2]: Entering directory `/home/public/nagle/x86/o.g'
/usr/bin/qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -I. -I/home/public/nagle/x86/o -I/home/public/nagle/x86/o.g -I/home/public/nagle/x86 -I/home/public/nagle -I/usr/include -g -DVARIANT_g /home/public/nagle/main.cc
/bin/rm -f /home/public/nagle/x86/o.g/nagle_g
/usr/bin/qcc -Vgcc_ntox86 -lang-c++ -o/home/public/nagle/x86/o.g/nagle_g main.o -L. -L/x86/lib -L/x86/usr/lib -g
/usr/bin/usemsg -s __USAGENTO -s __USAGE /home/public/nagle/x86/o.g/nagle_g /home/public/nagle/nagle.use
Bad format for load module /home/public/nagle/x86/o.g/nagle_g.
make[2]: *** [/home/public/nagle/x86/o.g/nagle_g] Error 1
make[2]: Leaving directory `/home/public/nagle/x86/o.g'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/public/nagle/x86'
make: *** [all] Error 2

Chris McKillop wrote:
John Nagle <nagle@downside.com> wrote:

Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc



Okie dokie - there is a bug in the qcc conf files on 6.2.0 when using
the gcc_ntox86_gpp target (the default for QCC on NC). On a PE machine
under 6.2.0 I can reproduce this bug using:

QCC -Vgcc_ntox86_gpp -g main.cc

However, on 6.2.1 this has been fixed (tested both GNU and Dinkum targets).

This doesn't appear to happen (on 6.2.0) when you use all the options provided
by the recursive make system for a debug target. You can try that out by
invoking "addvariant x86 o.g" and running make in x86/o.g.


chris


Chris McKillop wrote:
John Nagle <nagle@downside.com> wrote:

Ah. Unpack that tarball and try

QCC main.cc

and it works fine, producing an error message.

Now try

QCC -g main.cc



Okie dokie - there is a bug in the qcc conf files on 6.2.0 when using
the gcc_ntox86_gpp target (the default for QCC on NC). On a PE machine
under 6.2.0 I can reproduce this bug using:

QCC -Vgcc_ntox86_gpp -g main.cc

However, on 6.2.1 this has been fixed (tested both GNU and Dinkum targets).

This doesn't appear to happen (on 6.2.0) when you use all the options provided
by the recursive make system for a debug target. You can try that out by
invoking "addvariant x86 o.g" and running make in x86/o.g.


chris

--
cburgess@qnx.com

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Fri Feb 14, 2003 7:05 pm

Colin Burgess wrote:
I think that nagle_g in this case is probably a corrupt file, and that
ld is crashing somehow.
I agree. This whole problem revolves around the compiler
emitting bad object files, which then crash "ld".
What does file nagle_g say?
"data".
Did you try the -gstabs+?
That's not a documented QCC option on the
QCC manual page. Should I go back to standard
"gcc", rather than trying use QCC, so I can use
all the FSF "gcc" options?

John Nagle
Animats

Colin Burgess

Re: "ld" and "QCC" hang trying to link valid object file

Post by Colin Burgess » Fri Feb 14, 2003 7:06 pm

John Nagle <nagle@downside.com> wrote:
Colin Burgess wrote:

I think that nagle_g in this case is probably a corrupt file, and that
ld is crashing somehow.

I agree. This whole problem revolves around the compiler
emitting bad object files, which then crash "ld".

What does file nagle_g say?

"data".

Did you try the -gstabs+?

That's not a documented QCC option on the
QCC manual page. Should I go back to standard
"gcc", rather than trying use QCC, so I can use
all the FSF "gcc" options?
No, use QCC. -gstabs+ will work, I guess the docs for QCC are a little
light...

--
cburgess@qnx.com

John Nagle

Re: "ld" and "QCC" hang trying to link valid object file

Post by John Nagle » Sun Feb 16, 2003 4:11 am

Now that's a usable workaround. "QCC -gstabs+" is
getting me valid compiles, usable debug info, and correct
error messages on undefined symbols.

So the documentation for "QCC" needs an update. While
somebody is doing that, it would be good to clarify whether the
valid form for a target is "-Vgcc_ntox86" or "-V gcc_ntox86".
The documentation is ambiguous on that, and QCC
happily accepts both, although it's not clear what actually
happens.


John Nagle
Animats

Colin Burgess wrote:
No, use QCC. -gstabs+ will work, I guess the docs for QCC are a little
light...

David Gibbs

Re: "ld" and "QCC" hang trying to link valid object file

Post by David Gibbs » Mon Feb 17, 2003 10:03 pm

John Nagle <nagle@downside.com> wrote:
So the documentation for "QCC" needs an update. While
somebody is doing that, it would be good to clarify whether the
valid form for a target is "-Vgcc_ntox86" or "-V gcc_ntox86".
The documentation is ambiguous on that, and QCC
happily accepts both, although it's not clear what actually
happens.
Actually, both should be equally valid. Similarly "pidin -p6" and
"pidin -p 6" are both equally valid, and should have the same result.

(And, if QCC/qcc use getopt(), they won't normally be able to tell which way
you typed it.)

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

Post Reply

Return to “qdn.public.qnxrtp.devtools”