Problem building cross-debugger

Problem building cross-debugger

[Gerrit van Niekerk]

I am trying to use Cygwin to build a Cygwin host, DJGPP target version of GDB:
config --target=djgpp
All libraries seem to build ok (make does not stop), but the final link gives a number of undefined 
references:

`_bfd_i386_arch'
 `_cp_demangled_name_to_comp'
 `_cp_comp_to_string'
`_c_error'
`_objc_parse'
`_objc_error'
`_c_parse'
`c_emit_char'
 `_ada_parse'
`_ada_error'

What am I doing wrong?

I am using the latest CVS snapshot (2008-01-15).
Below is the full error list if it would help.

gcc -g -O2      \
                -o gdb.exe gdb.o libgdb.a \
                   ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libb
fd.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
     -lncurses -lm  -lexpat ../libiberty/libiberty.a -luser32
libgdb.a(exec.o): In function `legacy_register_sim_regno':
/cygdrive/c/develop/gdb20080115/src/gdb/arch-utils.c:44: undefined reference to
`_bfd_i386_arch'
libgdb.a(cp-support.o): In function `cp_canonicalize_string':
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:118: undefined reference to
 `_cp_demangled_name_to_comp'
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:123: undefined reference to
 `_cp_comp_to_string'
libgdb.a(cp-support.o): In function `mangled_name_to_comp':
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:166: undefined reference to
 `_cp_demangled_name_to_comp'
libgdb.a(cp-support.o): In function `cp_class_name_from_physname':
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:256: undefined reference to
 `_cp_comp_to_string'
libgdb.a(cp-support.o): In function `method_name_from_physname':
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:342: undefined reference to
 `_cp_comp_to_string'
libgdb.a(cp-support.o): In function `cp_func_name':
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:363: undefined reference to
 `_cp_demangled_name_to_comp'
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:371: undefined reference to
 `_cp_comp_to_string'
libgdb.a(cp-support.o): In function `overload_list_add_symbol':
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:390: undefined reference to
 `_cp_demangled_name_to_comp'
/cygdrive/c/develop/gdb20080115/src/gdb/cp-support.c:414: undefined reference to
 `_cp_comp_to_string'
libgdb.a(scm-lang.o): In function `scm_printstr':
/cygdrive/c/develop/gdb20080115/src/gdb/scm-lang.c:54: undefined reference to `_
c_error'
libgdb.a(objc-lang.o): In function `lookup_struct_typedef':
/cygdrive/c/develop/gdb20080115/src/gdb/objc-lang.c:98: undefined reference to `
_objc_parse'
/cygdrive/c/develop/gdb20080115/src/gdb/objc-lang.c:98: undefined reference to `
_objc_error'
libgdb.a(c-lang.o): In function `c_preprocess_and_parse':
/cygdrive/c/develop/gdb20080115/src/gdb/c-lang.c:298: undefined reference to `_c
_parse'
libgdb.a(c-lang.o): In function `c_emit_char':
/cygdrive/c/develop/gdb20080115/src/gdb/c-lang.c:70: undefined reference to `_c_
error'
/cygdrive/c/develop/gdb20080115/src/gdb/c-lang.c:67: undefined reference to `_c_
error'
libgdb.a(c-lang.o): In function `c_printchar':
/cygdrive/c/develop/gdb20080115/src/gdb/c-lang.c:78: undefined reference to `_c_
error'
libgdb.a(c-lang.o): In function `c_printstr':
/cygdrive/c/develop/gdb20080115/src/gdb/c-lang.c:111: undefined reference to `_c
_error'
libgdb.a(ada-lang.o): In function `parse':
/cygdrive/c/develop/gdb20080115/src/gdb/ada-lang.c:10639: undefined reference to
 `_ada_parse'
libgdb.a(ada-lang.o): In function `ada_print_array_index':
/cygdrive/c/develop/gdb20080115/src/gdb/ada-lang.c:333: undefined reference to `
_ada_error'
../bfd/libbfd.a(archures.o): In function `bfd_scan_arch':
/cygdrive/c/develop/gdb20080115/src/bfd/archures.c:622: undefined reference to `
_bfd_i386_arch'
Info: resolving _stdscr by linking to __imp__stdscr (auto-import)
Info: resolving _LINES by linking to __imp__LINES (auto-import)
Info: resolving _COLS by linking to __imp__COLS (auto-import)
Info: resolving _curscr by linking to __imp__curscr (auto-import)
collect2: ld returned 1 exit status
make[2]: *** [gdb.exe] Error 1
make[2]: Leaving directory `/cygdrive/c/develop/gdb20080115/src/CygwinDjgpp/gdb'

make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/cygdrive/c/develop/gdb20080115/src/CygwinDjgpp'
make: *** [all] Error 2

Re: Problem building cross-debugger

[Gerrit van Niekerk]

> I am trying to use Cygwin to build a Cygwin host, DJGPP target version of GDB:
> config --target=djgpp All libraries seem to build ok (make does not stop), but
> the final link gives a number of undefined references

I received no response to this request, but found that an old installation of diffutils with an 
incompatible cygwin1.dll caused many problems which were happily ignored by MAKE.

There is now only one undefined reference remaining: `_bfd_i386_arch'

I get this for a target of Cygwin (no cross-debugging) as well as for --target=djgpp. 
Any hint as to the cause will be appreciated.

Gerrit

 

Re: Problem building cross-debugger

[Gerrit van Niekerk]

>> I am trying to use Cygwin to build a Cygwin host, DJGPP target version of GDB: 
>> config --target=djgpp All libraries seem to build ok (make does not stop), but 
>> the final link gives a number of undefined references  

> There is now only one undefined reference remaining: `_bfd_i386_arch'

This is turning out to be a very one-sided thread :)
I managed to get the link phase to work by explicitly including ../bfd/cpu-i386.o in the gcc 
command doing the final link.  Perhaps the GDB maintainers can have a look at the cause of the 
problem.

BTW: The resulting cross-gdb is working like a charm :)

Re: Problem building cross-debugger

[Jim Blandy]

"Gerrit van Niekerk" <gerritvn at gpvno.co.za> writes:
>>> I am trying to use Cygwin to build a Cygwin host, DJGPP target version of GDB: 
>>> config --target=djgpp All libraries seem to build ok (make does not stop), but 
>>> the final link gives a number of undefined references  
>
>> There is now only one undefined reference remaining: `_bfd_i386_arch'
>
> This is turning out to be a very one-sided thread :)
> I managed to get the link phase to work by explicitly including
> ../bfd/cpu-i386.o in the gcc command doing the final link.  Perhaps
> the GDB maintainers can have a look at the cause of the problem.

I think the reason you haven't gotten much interaction is that you may
be the only person on the list who's working with such a
configuration.  If you could figure out the source of the problem and
suggest a patch, that would get things rolling.

Re: Problem building cross-debugger

[Gerrit van Niekerk]

On 18 Jan 2008 at 10:52, Jim Blandy wrote:
> I think the reason you haven't gotten much interaction is that you may
> be the only person on the list who's working with such a
> configuration.  If you could figure out the source of the problem and
> suggest a patch, that would get things rolling.

It is not really such an abnormal configuration. I tried building a standard Cygwin build, host and 
target using the current Cygwin release and latest CVS GDB and get the same problem. Trying to just 
figure out the makefiles generated by configure makes me dizzy! I already spent more than a week 
just getting it to produce an exe by hacking the screen output. 

I would love to supply a patch if somebody can just direct me to the place to start looking. Well I 
know it is somewhere in the bfd directory and that cpu-i386.o should probably be part of libbfd.a, 
but is not because objdump tells me so. Somebody familiar with the GDB build process can probably 
tell me in a few seconds what to look for and I am more than willing to assist to generate a patch 
for the gdb community at large even though my problem is currently resolved.


-- 
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax SA: 0866 413 555
Cell: +27(73)6891370
Fax Int'l: +1(206)2034139
Email: gerritvn@gpvno.co.za
Web: http://www.gpvno.co.za

Re: Problem building cross-debugger

[Michael Shatz]

Jim Blandy wrote:
> 
> 
> "Gerrit van Niekerk" <gerritvn at gpvno.co.za> writes:
>>>> I am trying to use Cygwin to build a Cygwin host, DJGPP target version
>>>> of GDB: 
>>>> config --target=djgpp All libraries seem to build ok (make does not
>>>> stop), but 
>>>> the final link gives a number of undefined references  
>>
>>> There is now only one undefined reference remaining: `_bfd_i386_arch'
>>
>> This is turning out to be a very one-sided thread :)
>> I managed to get the link phase to work by explicitly including
>> ../bfd/cpu-i386.o in the gcc command doing the final link.  Perhaps
>> the GDB maintainers can have a look at the cause of the problem.
> 
> I think the reason you haven't gotten much interaction is that you may
> be the only person on the list who's working with such a
> configuration.  If you could figure out the source of the problem and
> suggest a patch, that would get things rolling.
> 
> 

I got exactly the same problem building i386-elf target on i686-pc-cygwin
host with gcc 3.4.4. The problem exists both for binutils-2.16.1 and for
binutils-2.17.

Thank you, Gerrit. Your tip helped me to go on.
Other errors prevented me from building readelf.exe. Hopefullly I could live
with one from standard cygwin distribution.

-- 
View this message in context: http://www.nabble.com/Problem-building-cross-debugger-tp14897094p15419409.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: Problem building cross-debugger

[Michael Shatz]

Michael Shatz wrote:
> 
> 
> 
> Jim Blandy wrote:
>> 
>> 
>> "Gerrit van Niekerk" <gerritvn at gpvno.co.za> writes:
>>>>> I am trying to use Cygwin to build a Cygwin host, DJGPP target version
>>>>> of GDB: 
>>>>> config --target=djgpp All libraries seem to build ok (make does not
>>>>> stop), but 
>>>>> the final link gives a number of undefined references  
>>>
>>>> There is now only one undefined reference remaining: `_bfd_i386_arch'
>>>
>>> This is turning out to be a very one-sided thread :)
>>> I managed to get the link phase to work by explicitly including
>>> ../bfd/cpu-i386.o in the gcc command doing the final link.  Perhaps
>>> the GDB maintainers can have a look at the cause of the problem.
>> 
>> I think the reason you haven't gotten much interaction is that you may
>> be the only person on the list who's working with such a
>> configuration.  If you could figure out the source of the problem and
>> suggest a patch, that would get things rolling.
>> 
>> 
> 
> I got exactly the same problem building i386-elf target on i686-pc-cygwin
> host with gcc 3.4.4. The problem exists both for binutils-2.16.1 and for
> binutils-2.17.
> 
> Thank you, Gerrit. Your tip helped me to go on.
> Other errors prevented me from building readelf.exe. Hopefullly I could
> live with one from standard cygwin distribution.
> 
> 

Finally found the problem.

It's all about cygwin "textmode" mount huck.
When the build drive (or may be source, or both, in my case they were the
same) is mounted in the text mode the following command misbehaves:
/bin/sh ./libtool --tag=CC --mode=link i686-pc-cygwin-gcc -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2   -o libbfd.la
-rpath /usr/local/emb386/i686-pc-cygwin/i386-elf/lib -release `cat
libtool-soversion`  archive.lo archures.lo bfd.lo bfdio.lo bfdwin.lo
cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo opncls.lo
reloc.lo section.lo syms.lo targets.lo hash.lo linker.lo srec.lo binary.lo
tekhex.lo ihex.lo stabs.lo stab-syms.lo merge.lo dwarf2.lo simple.lo `cat
ofiles`  

Either 'libtool' or, more likely, 'sh' somehow ignores the tail of the
'ofiles' file which happens to contain the  cpu-i386.o

When running from binary-mounted drive everything compiles as expected.
Hope it helps.




-- 
View this message in context: http://www.nabble.com/Problem-building-cross-debugger-tp14897094p15461364.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: Problem building cross-debugger

[Gerrit van Niekerk]

On 13 Feb 2008 at 9:49, Michael Shatz wrote:
> Finally found the problem.
> 
> It's all about cygwin "textmode" mount huck.
> When the build drive (or may be source, or both, in my case they were the
> same) is mounted in the text mode the following command misbehaves:
> /bin/sh ./libtool --tag=CC --mode=link i686-pc-cygwin-gcc -W -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2   -o libbfd.la
> -rpath /usr/local/emb386/i686-pc-cygwin/i386-elf/lib -release `cat
> libtool-soversion`  archive.lo archures.lo bfd.lo bfdio.lo bfdwin.lo
> cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo opncls.lo
> reloc.lo section.lo syms.lo targets.lo hash.lo linker.lo srec.lo binary.lo
> tekhex.lo ihex.lo stabs.lo stab-syms.lo merge.lo dwarf2.lo simple.lo `cat
> ofiles`  
> 
> Either 'libtool' or, more likely, 'sh' somehow ignores the tail of the
> 'ofiles' file which happens to contain the  cpu-i386.o
> 
> When running from binary-mounted drive everything compiles as expected.

Must admit: I don't know much about Cygwin - basically run the Cygwin 
Bash shell and enter the rquired commands which do not include mounting 
anything. What do I have to change to do a binary mount?
-- 
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax SA: 0866 413 555
Cell: +27(73)6891370
Fax Int'l: +1(206)2034139
Email: gerritvn@gpvno.co.za
Web: http://www.gpvno.co.za

RE: Problem building cross-debugger

[Dave Korn]

On 13 February 2008 17:49, Michael Shatz wrote:

> Finally found the problem.
> 
> It's all about cygwin "textmode" mount huck.

  And that really *is* a hack.  We deeply advise not using it, or just using
it as somewhere to store some datafiles so that when you copy them from there
to/from your main filesystem tree they get converted back and forth
automatically, but working in a textmode-mounted tree is just very very hard
to get right.

> When the build drive (or may be source, or both, in my case they were the
> same) is mounted in the text mode the following command misbehaves:
> /bin/sh ./libtool --tag=CC --mode=link i686-pc-cygwin-gcc -W -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2   -o libbfd.la
> -rpath /usr/local/emb386/i686-pc-cygwin/i386-elf/lib -release `cat
> libtool-soversion`  archive.lo archures.lo bfd.lo bfdio.lo bfdwin.lo
> cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo opncls.lo
> reloc.lo section.lo syms.lo targets.lo hash.lo linker.lo srec.lo binary.lo
> tekhex.lo ihex.lo stabs.lo stab-syms.lo merge.lo dwarf2.lo simple.lo `cat
> ofiles`
> 
> Either 'libtool' or, more likely, 'sh' somehow ignores the tail of the
> 'ofiles' file which happens to contain the  cpu-i386.o

  Ah, yes, it would.  "cat" always opens files in binary mode (by design, this
is part of the spec) so when it reads "ofiles" the entries in it
(one-per-line) don't look like a filename plus a CRLF line-end, they look like
a filename (of which the last char is coincidentally a CR) plus a LF line-end.
As there is no such file as "../bfd/cpu-i386.o^M", it gets skipped.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Problem building cross-debugger

[Brian Dessent]

Gerrit van Niekerk wrote:

> Must admit: I don't know much about Cygwin - basically run the Cygwin
> Bash shell and enter the rquired commands which do not include mounting
> anything. What do I have to change to do a binary mount?

It is one of the options presented when you ran the installer (and note
that it recommends binary.)  You can change it the next time you run
setup for package updates, or you can change it manually with the mount
command.  See mount(1) or run "mount -m" to get a list of commands that
if run would re-create the current mount table -- if you change the -t
to -b and run them they will be binmode instead of textmode.

Brian