Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour

Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour

[Fredrik Öhrström]

Sorry to bother you all about this again.....
Since I could not make the compiler work with Martins old patch I 
decided to go for the -fno-vtable-thunks approach.
Unfortunately I am having severe troubles with recompiling glibc and
gcc.

The goal is to recompile my C++ programs with -fno-vtable-thunks,
however because of the binary incompatibility I have to recompile
both the stdc++ library and glibc. (If I understood correctly)

-- Compiler ---------------
I have recompiled gcc 2.95.1 with -fno-vtable-thunks (made the change
in config/mt-linux.h, configured and make bootstrap) and installed it
in /usr/local/gcc. I believe that this created a compiler that
compiles everything with no-vtable-thunks and a newly compiled stdc++
library  that is compiled with -fno-vtable-thunks.

-- Glibc ------------------
Then I compiled glibc with this new compiler. Had to change in
the configure script to allow the 2.95.1 compiler and to add
the link crypt/sysdeps/unix/libc-lock.h to 
glibc-2.1.1/sysdeps/generic/bits/libc-lock.h

After that compilation went ok and make check was ok.

-- Compiling problems with old libraries -------------------
I can compile and run a testprogram with the old glibc libraries
(libc-2.1.1.so with thunks):
int main(){return 42;}

When I compile a test program containing c++ like:
#include<iostream.h> int main(){cout<<"Hello"<<endl;}
I get three:

/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/libstdc++.a(stdstrbufs.o)(.data+0xb4):
undefined reference to `filebuf virtual table'

-- Running problems with new libraries ----------------
If set LD_LIBRARY_PATH to /usr/local/glib/lib whatever I run I get:
./a.out: /lib/ld-linux.so.2: version `GLIBC_2.1.1' not found
(required by /usr/local/glibc/lib/libc.so.6)

-- My guesses ---------------
I assume that I in some way must tell gcc to use the new glibc
library when compiling new stuff but I am completely lost here.....

Am I on the right track? Any help would be greatly appreciated!

Thanks
Fredrik Ohrstrom

Re: Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour

[Martin v. Loewis]

> /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/libstdc++.a(stdstrbufs.o)(.data+0xb4):
> undefined reference to `filebuf virtual table'
> 
[...]
> I assume that I in some way must tell gcc to use the new glibc
> library when compiling new stuff but I am completely lost here.....
> 
> Am I on the right track? Any help would be greatly appreciated!

If vtable thunks are not used, mangling of the vtable changes: It
either starts with '__vt.' or '__vt_'. It appears that libstdc++
requires a different symbol than you have available.

This, in turn, could result from an incorrect contents of _G_config.h,
which explains the C++ vtable mechanism to C applications. You'll
probably have numerous copies of a file with that name. Make sure you
are using the right one consistently. The one that comes with glibc is
probably wrong if you are not using vtable thunks and needs to be
replaced.

Regards,
Martin

Almost got glibc working with no-vtable-thunks, but ....

[Fredrik Öhrström]

> This, in turn, could result from an incorrect contents of _G_config.h,
> which explains the C++ vtable mechanism to C applications. You'll

Found it. Everything seems to build correctly now. The generated 
files contains _vt. prefixes for the virtual tables instead of _vt_

I examined what the glibc "make check" command did to compile
testprograms with the new library. With that information I managed
to compile a single HelloWorld C program and link with the new
library! :-)

But when I try the following C++ program I get several link 
errors of this kind:
/usr/local/gcc/lib/libstdc++.a.2.10.0(iostream.o): In function
`_IO_ostream_with assign type_info function':
/home/foh/Code/gccobjdir/i686-pc-linux-gnu/libio/../../../gcc-2.95.1/libio/iostr
eam.h(.gnu.linkonce.t._._8iostream+0xc9): undefined reference to
`__builtin_vec_delete'

The program looks like this:

#include<stdio.h>
#include<iostream.h>

struct Alfa
{
        virtual int a() = 0;
};


struct Beta : public Alfa
{
        int a () 
        {
                return 47;
        }
};


int main()
{
        printf ("Hello World!\n");        
        cout << "Hello World!" << endl;
        Beta b;
        
        return b.a();        
}

And the makefile looks like this:

all: compile link 

compile: test.cc
	g++ test.cc -c -g 
-DNLSPATH='"/usr/local/glibc/share/locale/%L/%N:/usr/local/glibc/share/locale/%L/LC_MESSAGES/%N:/usr/local/glibc/share/locale/%l/%N:/usr/local/glibc/share/locale/%l/LC_MESSAGES/%N:"'
-DHAVE_CONFIG_H -D_LIBC_REENTRANT -o test.o

link: test.o
	gcc -nostdlib -nostartfiles -o test
-Wl,-dynamic-linker=/usr/local/glibc/lib/ld-linux.so.2
/usr/local/glibc/lib/crt1.o /usr/local/glibc/lib/crti.o `gcc
--print-file-name=crtbegin.o` test.o
-Wl,-rpath-link=/usr/local/glibc/lib /usr/local/glibc/lib/libc.so.6
/usr/local/glibc/lib/libc_nonshared.a -lgcc `gcc
--print-file-name=crtend.o` /usr/local/glibc/lib/crtn.o
/usr/local/gcc/lib/libstdc++.a.2.10.0 

(Sorry for the linebreaks...)

What do I link in to find these rather important methods?
I thought that earlier you had to explicitly link in -lg++ 
but now I can't find any library with that name.

Thanks!
Fredrik Ohrstrom

Re: Almost got glibc working with no-vtable-thunks, but ....

[Martin v. Loewis]

> eam.h(.gnu.linkonce.t._._8iostream+0xc9): undefined reference to
> `__builtin_vec_delete'
[...]
>	gcc -nostdlib -nostartfiles -o test
[...]
> What do I link in to find these rather important methods?
> I thought that earlier you had to explicitly link in -lg++ 
> but now I can't find any library with that name.

These functions are in libgcc.a. You really should *not* link with
nostdlib nostartfiles, providing them manually. Instead, you need to
get the specs file right so it takes the right libraries from the
right places.

In this particular case, the problem seems to be that you pass
libstdc++ *after* providing libgcc.

Another general hint: Use nm(1) to find out which library provides
which symbol.

Regards,
Martin

Re: Almost got glibc working with no-vtable-thunks, but ....

[Fredrik Öhrström]

On Wed, 15 Sep 1999, Martin v. Loewis wrote:

> In this particular case, the problem seems to be that you pass
> libstdc++ *after* providing libgcc.

Thanks! Now it compiles, but.....

I managed to cut the makefile down to this:---------------------

test.o: test.cc
	g++ test.cc -c -g

test: test.o
	g++ -g -o test test.o -Wl,-rpath-link=/usr/local/glibc/lib
/usr/local/glibc/lib/libc.so.6 /usr/local/glibc/lib/libc_nonshared.a  

run:
	/usr/local/glibc/lib/ld-linux.so.2 --library-path
/usr/local/glibc/lib /home/foh/test 

And the test program looks like this:--------------------------

#include<stdio.h>
#include<iostream.h>

int main()
{
        printf ("Alfa\n");        
        cerr << "Beta" << endl;
        printf ("Gamma\n");                
}

The changes I did in the specs file
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs look like
this:---------------------------------------------------------

> diff specs specs.original

17c17
< %{!shared:crtend.o%s} %{shared:crtendS.o%s}
/usr/local/glibc/lib/crtn.o%s
---
> %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
29c29
< %{!shared:      %{pg:/usr/local/glibc/lib/gcrt1.o%s}
%{!pg:%{p:/usr/local/glibc/lib/gcrt1.o%s}
%{!p:%{profile:/usr/local/glibc/lib/gcrt1.o%s}
%{!profile:/usr/local/glibc/lib/crt1.o%s}}}}
/usr/local/glibc/lib/crti.o%s %{!shared:crtbegin.o%s}
%{shared:crtbeginS.o%s}
---
> %{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s}
%{!p:%{profile:gcrt1.o%s}
%{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s}
%{shared:crtbeginS.o%s}

However to output from the program looks like this:----------
Alfa

Gamma

The text sent to cerr is lost, but not the linefeed!!!!!

One other thing is that specs changes are not necessary, it
compiles and runs with the same bug anyway. Does that mean that
the crt* files are binary compatible and it picks the old ones?

Thanks for all the help so far. 

Fredrik

Re: Almost got glibc working with no-vtable-thunks, but ....

[Martin v. Loewis]

Frederik,

It seems this is the point where I have to leave you on your own; with
all the changes you made to various tools and libraries, I can't guess
anymore what's going on.

> The text sent to cerr is lost, but not the linefeed!!!!!

I have no clue; you'll probably have to debug this to find out.

> One other thing is that specs changes are not necessary, it
> compiles and runs with the same bug anyway. Does that mean that
> the crt* files are binary compatible and it picks the old ones?

Yes, the crt* files should be binary compatible. To find out exactly
which ones it uses, pass --verbose to ld(1), preferably via
-Wl,--verbose.

Good luck,
Martin

Re: Almost got glibc working with no-vtable-thunks, but ....

[Fredrik Öhrström]

On Wed, 15 Sep 1999, Martin v. Loewis wrote:

> In this particular case, the problem seems to be that you pass
> libstdc++ *after* providing libgcc.

Thanks! Now it compiles, but.....

I managed to cut the makefile down to this:---------------------

test.o: test.cc
	g++ test.cc -c -g

test: test.o
	g++ -g -o test test.o -Wl,-rpath-link=/usr/local/glibc/lib
/usr/local/glibc/lib/libc.so.6 /usr/local/glibc/lib/libc_nonshared.a  

run:
	/usr/local/glibc/lib/ld-linux.so.2 --library-path
/usr/local/glibc/lib /home/foh/test 

And the test program looks like this:--------------------------

#include<stdio.h>
#include<iostream.h>

int main()
{
        printf ("Alfa\n");        
        cerr << "Beta" << endl;
        printf ("Gamma\n");                
}

The changes I did in the specs file
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs look like
this:---------------------------------------------------------

> diff specs specs.original

17c17
< %{!shared:crtend.o%s} %{shared:crtendS.o%s}
/usr/local/glibc/lib/crtn.o%s
---
> %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
29c29
< %{!shared:      %{pg:/usr/local/glibc/lib/gcrt1.o%s}
%{!pg:%{p:/usr/local/glibc/lib/gcrt1.o%s}
%{!p:%{profile:/usr/local/glibc/lib/gcrt1.o%s}
%{!profile:/usr/local/glibc/lib/crt1.o%s}}}}
/usr/local/glibc/lib/crti.o%s %{!shared:crtbegin.o%s}
%{shared:crtbeginS.o%s}
---
> %{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s}
%{!p:%{profile:gcrt1.o%s}
%{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s}
%{shared:crtbeginS.o%s}

However to output from the program looks like this:----------
Alfa

Gamma

The text sent to cerr is lost, but not the linefeed!!!!!

One other thing is that specs changes are not necessary, it
compiles and runs with the same bug anyway. Does that mean that
the crt* files are binary compatible and it picks the old ones?

Thanks for all the help so far. 

Fredrik

Almost got glibc working with no-vtable-thunks, but ....

[Fredrik Öhrström]

> This, in turn, could result from an incorrect contents of _G_config.h,
> which explains the C++ vtable mechanism to C applications. You'll

Found it. Everything seems to build correctly now. The generated 
files contains _vt. prefixes for the virtual tables instead of _vt_

I examined what the glibc "make check" command did to compile
testprograms with the new library. With that information I managed
to compile a single HelloWorld C program and link with the new
library! :-)

But when I try the following C++ program I get several link 
errors of this kind:
/usr/local/gcc/lib/libstdc++.a.2.10.0(iostream.o): In function
`_IO_ostream_with assign type_info function':
/home/foh/Code/gccobjdir/i686-pc-linux-gnu/libio/../../../gcc-2.95.1/libio/iostr
eam.h(.gnu.linkonce.t._._8iostream+0xc9): undefined reference to
`__builtin_vec_delete'

The program looks like this:

#include<stdio.h>
#include<iostream.h>

struct Alfa
{
        virtual int a() = 0;
};


struct Beta : public Alfa
{
        int a () 
        {
                return 47;
        }
};


int main()
{
        printf ("Hello World!\n");        
        cout << "Hello World!" << endl;
        Beta b;
        
        return b.a();        
}

And the makefile looks like this:

all: compile link 

compile: test.cc
	g++ test.cc -c -g 
-DNLSPATH='"/usr/local/glibc/share/locale/%L/%N:/usr/local/glibc/share/locale/%L/LC_MESSAGES/%N:/usr/local/glibc/share/locale/%l/%N:/usr/local/glibc/share/locale/%l/LC_MESSAGES/%N:"'
-DHAVE_CONFIG_H -D_LIBC_REENTRANT -o test.o

link: test.o
	gcc -nostdlib -nostartfiles -o test
-Wl,-dynamic-linker=/usr/local/glibc/lib/ld-linux.so.2
/usr/local/glibc/lib/crt1.o /usr/local/glibc/lib/crti.o `gcc
--print-file-name=crtbegin.o` test.o
-Wl,-rpath-link=/usr/local/glibc/lib /usr/local/glibc/lib/libc.so.6
/usr/local/glibc/lib/libc_nonshared.a -lgcc `gcc
--print-file-name=crtend.o` /usr/local/glibc/lib/crtn.o
/usr/local/gcc/lib/libstdc++.a.2.10.0 

(Sorry for the linebreaks...)

What do I link in to find these rather important methods?
I thought that earlier you had to explicitly link in -lg++ 
but now I can't find any library with that name.

Thanks!
Fredrik Ohrstrom

Re: Almost got glibc working with no-vtable-thunks, but ....

[Martin v. Loewis]

Frederik,

It seems this is the point where I have to leave you on your own; with
all the changes you made to various tools and libraries, I can't guess
anymore what's going on.

> The text sent to cerr is lost, but not the linefeed!!!!!

I have no clue; you'll probably have to debug this to find out.

> One other thing is that specs changes are not necessary, it
> compiles and runs with the same bug anyway. Does that mean that
> the crt* files are binary compatible and it picks the old ones?

Yes, the crt* files should be binary compatible. To find out exactly
which ones it uses, pass --verbose to ld(1), preferably via
-Wl,--verbose.

Good luck,
Martin

Re: Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour

[Martin v. Loewis]

> /usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/libstdc++.a(stdstrbufs.o)(.data+0xb4):
> undefined reference to `filebuf virtual table'
> 
[...]
> I assume that I in some way must tell gcc to use the new glibc
> library when compiling new stuff but I am completely lost here.....
> 
> Am I on the right track? Any help would be greatly appreciated!

If vtable thunks are not used, mangling of the vtable changes: It
either starts with '__vt.' or '__vt_'. It appears that libstdc++
requires a different symbol than you have available.

This, in turn, could result from an incorrect contents of _G_config.h,
which explains the C++ vtable mechanism to C applications. You'll
probably have numerous copies of a file with that name. Make sure you
are using the right one consistently. The one that comes with glibc is
probably wrong if you are not using vtable thunks and needs to be
replaced.

Regards,
Martin

Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour

[Fredrik Öhrström]

Sorry to bother you all about this again.....
Since I could not make the compiler work with Martins old patch I 
decided to go for the -fno-vtable-thunks approach.
Unfortunately I am having severe troubles with recompiling glibc and
gcc.

The goal is to recompile my C++ programs with -fno-vtable-thunks,
however because of the binary incompatibility I have to recompile
both the stdc++ library and glibc. (If I understood correctly)

-- Compiler ---------------
I have recompiled gcc 2.95.1 with -fno-vtable-thunks (made the change
in config/mt-linux.h, configured and make bootstrap) and installed it
in /usr/local/gcc. I believe that this created a compiler that
compiles everything with no-vtable-thunks and a newly compiled stdc++
library  that is compiled with -fno-vtable-thunks.

-- Glibc ------------------
Then I compiled glibc with this new compiler. Had to change in
the configure script to allow the 2.95.1 compiler and to add
the link crypt/sysdeps/unix/libc-lock.h to 
glibc-2.1.1/sysdeps/generic/bits/libc-lock.h

After that compilation went ok and make check was ok.

-- Compiling problems with old libraries -------------------
I can compile and run a testprogram with the old glibc libraries
(libc-2.1.1.so with thunks):
int main(){return 42;}

When I compile a test program containing c++ like:
#include<iostream.h> int main(){cout<<"Hello"<<endl;}
I get three:

/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/libstdc++.a(stdstrbufs.o)(.data+0xb4):
undefined reference to `filebuf virtual table'

-- Running problems with new libraries ----------------
If set LD_LIBRARY_PATH to /usr/local/glib/lib whatever I run I get:
./a.out: /lib/ld-linux.so.2: version `GLIBC_2.1.1' not found
(required by /usr/local/glibc/lib/libc.so.6)

-- My guesses ---------------
I assume that I in some way must tell gcc to use the new glibc
library when compiling new stuff but I am completely lost here.....

Am I on the right track? Any help would be greatly appreciated!

Thanks
Fredrik Ohrstrom

Re: Almost got glibc working with no-vtable-thunks, but ....

[Martin v. Loewis]

> eam.h(.gnu.linkonce.t._._8iostream+0xc9): undefined reference to
> `__builtin_vec_delete'
[...]
>	gcc -nostdlib -nostartfiles -o test
[...]
> What do I link in to find these rather important methods?
> I thought that earlier you had to explicitly link in -lg++ 
> but now I can't find any library with that name.

These functions are in libgcc.a. You really should *not* link with
nostdlib nostartfiles, providing them manually. Instead, you need to
get the specs file right so it takes the right libraries from the
right places.

In this particular case, the problem seems to be that you pass
libstdc++ *after* providing libgcc.

Another general hint: Use nm(1) to find out which library provides
which symbol.

Regards,
Martin