From: pavenis AT lanet DOT lv
To: Will Robinson <wsr23 AT Stanford DOT EDU>, djgpp AT delorie DOT com
Date: Tue, 28 Aug 2001 11:06:27 +0300
MIME-Version: 1.0
Subject: Re: linux->dos cross-compiler
Message-ID: <3B8B7B33.19742.1C1528@localhost>
References: <3B87B4F3 DOT 22540 DOT 33D4FC AT localhost>
In-reply-to: <Pine.GSO.4.31.0108271438220.6965-100000@elaine10.Stanford.EDU>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Reply-To: djgpp AT delorie DOT com

On 27 Aug 2001 at 14:57, Will Robinson wrote:

> > > string.cpp: In function `int main()':
> > > string.cpp:5: `string' undeclared (first use this function)
> > > string.cpp:5: (Each undeclared identifier is reported only once for each
> > >    function it appears in.)
> > > string.cpp:5: parse error before `=' token
> >
> > string class is now namespace std.
> 
> Doh!  Please pardon my ignorance...adding
>   using std::string
> and such throughout the code has allowed me to compile all the source
> files!
> 
> Now for (hopefully the last) hurdle...linking.  I've had to do some (I
> think) odd things to get my code to even come close to linking:
> 
> -Explicitly included crt0.o in the list of object files to link.
> -Put -lc -lstdc++ -lgcc at the end of the linker command line.
> 
> And I still get errors like these:
> 
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libgcc.a(unwind-dw2-fde.o): In function
> `read_encoded_value_with_base':
> unwind-dw2-fde.c:211: multiple definition of `__register_frame_info'
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libc.a(rfinfo.o)(.text+0x0):rfinfo.c:
> first defined here
> 

Last time I built Linux to DJGPP cross-compiler some months ago  and saw no similar problems. But it 
was after applying some patches (all should be in gcc30s2.zip) Perhaps I'll redo that sometimes with gcc-
3.0.1, but I cannot say now when.

> 
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libgcc.a(unwind-dw2.o): In function
> `read_encoded_value_with_base':
> unwind-dw2.c:211: undefined reference to `strlen'
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libgcc.a(unwind-dw2-fde.o): In function
> `base_from_object':
> unwind-dw2-fde.c:231: undefined reference to `strlen'
>
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libstdc++.a(locale.o): In function
> `std::locale::global(std::locale const&)':
> locale.cc:717: undefined reference to `setlocale'
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libstdc++.a(locale.o): In function
> `std::ctype<char>::do_toupper(char*, char const*) const':
> locale.cc:55: undefined reference to `toupper'
> /opt/djgpp/i586-pc-msdosdjgpp/lib/libstdc++.a(locale.o): In function
> `std::ctype<char>::do_tolower(char*, char const*) const':
> locale.cc:70: undefined reference to `tolower'
> 
> 
> So it looks like __register_frame_info is defined both in libc.a and
> libgcc.a, and that ld-dos isn't seeing the definitions of strlen,
> setlocale, toupper, and tolower.  I don't know what to do about the first
> problem , but the second is especially puzzling, since running
>   nm-dos libc.a --print-file-name | grep strlen
> gives:
> 
> libc.a:strlen.o:00000024 b .bss
> libc.a:strlen.o:00000024 d .data
> libc.a:strlen.o:00000000 t .text
> libc.a:strlen.o:00000000 t ___gnu_compiled_c
> libc.a:strlen.o:00000000 T _strlen
> libc.a:strlen.o:00000000 t gcc2_compiled.
> libc.a:c1args.o:0000004c t _far_strlen
> 
> And I get similar results for toupper, tolower, and setlocale.  When I add
> a --verbose switch to my ld-dos command line, I find that it is indeed
> using the right libc.a library, and is accessing a lot of files from it...
> 
> attempt to open /opt/djgpp/i586-pc-msdosdjgpp/lib/libc.a succeeded
> (/opt/djgpp/i586-pc-msdosdjgpp/lib/libc.a)printf.o
> (/opt/djgpp/i586-pc-msdosdjgpp/lib/libc.a)npxsetup.o
> (/opt/djgpp/i586-pc-msdosdjgpp/lib/libc.a)fflush.o
> .
> ...but that strlen.o, toupper.o, tolower.o, and setlocal.o are not in the
> list of files loaded.  It's possible that other files are missing also,
> but these 4 symbols are the only things turning up as unresolved in what
> I'm currently trying to compile.  Any idea why they would show up in nm
> but not be included during linking?
> 
> One thing's for sure...if I ever get this working correctly I'm going to
> write up a nice long account of how it was done!

As I said last time I tried it built for me without problems (but I applied the same patches I'm applying to 
build native compiler for DJGPP). I used this cross-compiler to cross-build the same gcc version as native 
compiler for DJGPP (In this case there were some 
minor problems, but not serious ones)

Andris