From: hat AT se-46 DOT wpa DOT wtb DOT tue DOT nl (Albert Theo Hofkamp)
Newsgroups: gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp
Subject: repo-patch works on Linux, not on DJGPP !
Date: 24 Sep 1997 09:08:27 GMT
Organization: Eindhoven University of Technology, The Netherlands
Lines: 111
Message-ID: <60alab$a0j@tuegate.tue.nl>
Reply-To: a DOT hofkamp AT wtb DOT tue DOT nl
NNTP-Posting-Host: se-46.wpa.wtb.tue.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Hello All,

I am trying to get the repo-patch up & running on the DJGPP DOS port of the
GNU compiler.

For this purpose, I have 2 compilers on my Linux box:
g++ the native Linux gcc compiler
gcc-dos the cross (GNU) compiler to DJGPP

Both compilers are built using gcc2.7.2.2, with repo-patch 2.7.0
The -frepo option works on g++, but not on gcc-dos.

When I try to compile the following files, with verbose repo linking
(environment variable `export TLINK_VERBOSE=3'):
--- BEGIN main.cc ---
extern void sub();
int main() { sub(); return 0; }
--- END main.cc ---
--- BEGIN sub.cc ---
#include <list>
void sub() { list<int> li; li.push_back(1); }
--- END sub.cc ---

When compiling the sub.cc program, and comparing both sub.rpo files, both
files are equal in size, and the contents is only slightly different:
$ diff sub.rpo.g++ sub.rpo.gcc-dos | c++filt
9c9
< O swap(unsigned int &, unsigned int &)
---
> O swap(unsigned long &, unsigned long &)
14c14
< O max(unsigned int const &, unsigned int const &)
---
> O max(unsigned long const &, unsigned long const &)
31c31
< O _._t4list1Zi
---
> O _$_t4list1Zi
34c34
< O __t4list1ZiUiRCi
---
> O __t4list1ZiUlRCi
41c41
< O list<int>::insert(list<int>::iterator, unsigned int, int const &)
---
> O list<int>::insert(list<int>::iterator, unsigned long, int const &)
115c115
< O allocator<list<int>::list_node>::allocate(unsigned int)
---
> O allocator<list<int>::list_node>::allocate(unsigned long)
124c124
< O allocator<int>::allocate(unsigned int)
---
> O allocator<int>::allocate(unsigned long)

(Note the c++filt in the pipe).
The difference lies in using long instead of int. These differences do not
seem dangerous to me.

During linking however, both compilers show different behaviour:

First the gcc-dos output during linking:
$ gcc-dos -frepo main.o sub.o
sub.o(.text+0xb):sub.cc: undefined reference to `list<int>::_(void)'
sub.o(.text+0x22):sub.cc: undefined reference to `list<int>::_push_back(int const &)'
sub.o(.text+0x30):sub.cc: undefined reference to `__$_t4list1Zi'
$

The g++ output is simular, but here the -frepo works:
$ g++ -frepo main.o sub.o
collect: reading sub.rpo
sub.o: In function `sub(void)':
sub.o(.text+0xb): undefined reference to `list<int>::list(void)'
sub.o(.text+0x22): undefined reference to `list<int>::push_back(int const &)'
sub.o(.text+0x30): undefined reference to `list<int>::~list(void)'
collect: tweaking __t4list1Zi in sub.rpo
collect: tweaking push_back__t4list1ZiRCi in sub.rpo
[remaining diagnostic lines deleted, but the linking succeeds]
$

The difference between both compilers is
a) The line `reading sub.rpo'
b) the `_' after the double colon in the template instantiations.

Difference a worries me a bit, but maybe the .rpo file is read only when
template instantiations are needed.
The other difference is the use of a `_' as prefix. Since gcc-dos works with
other programs, this has to be some convention used within the dos compiler.
However, the difference seems enough to throw the repo-patch off-track.

I am not sure how to solve this problem. Changing the linker is not really
an option, as the entire gcc-dos compiler and its libraries works with these
conventions.
I could try to use repo-patch 2.7.2 instead of 2.7.0, but I don't know what
difference that would make (does any-one know the difference between both
versions ?).
As far as I can see, the only option left is start hacking in the gcc-code,
something I don't really like, as it will cost me a lot of time learning
about the internals of gcc.

Maybe I should first try to establish whether my hypothesis about the prefix
is correct. Does any one know a way to test this ?


Sorry for not being able to give more insight in the problem, but I am quite
lost here at the moment :-(

Any help is appreciated,
Albert
---
Freedom: A Linux-based GNU computer system