* Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour
[not found] <199909022230.AAA00668@mira.isdn.cs.tu-berlin.de>
@ 1999-09-14 6:36 ` Fredrik Ãhrström
1999-09-14 14:08 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
0 siblings, 2 replies; 12+ messages in thread
From: Fredrik ÃÂhrström @ 1999-09-14 6:36 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: gcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour
1999-09-14 6:36 ` Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour Fredrik Ãhrström
@ 1999-09-14 14:08 ` Martin v. Loewis
1999-09-15 9:06 ` Almost got glibc working with no-vtable-thunks, but Fredrik Ãhrström
1999-09-30 18:02 ` Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1 sibling, 2 replies; 12+ messages in thread
From: Martin v. Loewis @ 1999-09-14 14:08 UTC (permalink / raw)
To: d92-foh; +Cc: gcc
> /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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Almost got glibc working with no-vtable-thunks, but ....
1999-09-14 14:08 ` Martin v. Loewis
@ 1999-09-15 9:06 ` Fredrik Ãhrström
1999-09-15 15:05 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1999-09-30 18:02 ` Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour Martin v. Loewis
1 sibling, 2 replies; 12+ messages in thread
From: Fredrik ÃÂhrström @ 1999-09-15 9:06 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Almost got glibc working with no-vtable-thunks, but ....
1999-09-15 9:06 ` Almost got glibc working with no-vtable-thunks, but Fredrik Ãhrström
@ 1999-09-15 15:05 ` Martin v. Loewis
1999-09-16 3:50 ` Fredrik Ãhrström
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1 sibling, 2 replies; 12+ messages in thread
From: Martin v. Loewis @ 1999-09-15 15:05 UTC (permalink / raw)
To: d92-foh; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Almost got glibc working with no-vtable-thunks, but ....
1999-09-15 15:05 ` Martin v. Loewis
@ 1999-09-16 3:50 ` Fredrik Ãhrström
1999-09-16 10:37 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1999-09-30 18:02 ` Martin v. Loewis
1 sibling, 2 replies; 12+ messages in thread
From: Fredrik ÃÂhrström @ 1999-09-16 3:50 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: gcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Almost got glibc working with no-vtable-thunks, but ....
1999-09-16 3:50 ` Fredrik Ãhrström
@ 1999-09-16 10:37 ` Martin v. Loewis
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1 sibling, 1 reply; 12+ messages in thread
From: Martin v. Loewis @ 1999-09-16 10:37 UTC (permalink / raw)
To: d92-foh; +Cc: gcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Almost got glibc working with no-vtable-thunks, but ....
1999-09-16 10:37 ` Martin v. Loewis
@ 1999-09-30 18:02 ` Martin v. Loewis
0 siblings, 0 replies; 12+ messages in thread
From: Martin v. Loewis @ 1999-09-30 18:02 UTC (permalink / raw)
To: d92-foh; +Cc: gcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Almost got glibc working with no-vtable-thunks, but ....
1999-09-16 3:50 ` Fredrik Ãhrström
1999-09-16 10:37 ` Martin v. Loewis
@ 1999-09-30 18:02 ` Fredrik Ãhrström
1 sibling, 0 replies; 12+ messages in thread
From: Fredrik ÃÂhrström @ 1999-09-30 18:02 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: gcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Almost got glibc working with no-vtable-thunks, but ....
1999-09-15 15:05 ` Martin v. Loewis
1999-09-16 3:50 ` Fredrik Ãhrström
@ 1999-09-30 18:02 ` Martin v. Loewis
1 sibling, 0 replies; 12+ messages in thread
From: Martin v. Loewis @ 1999-09-30 18:02 UTC (permalink / raw)
To: d92-foh; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Almost got glibc working with no-vtable-thunks, but ....
1999-09-15 9:06 ` Almost got glibc working with no-vtable-thunks, but Fredrik Ãhrström
1999-09-15 15:05 ` Martin v. Loewis
@ 1999-09-30 18:02 ` Fredrik Ãhrström
1 sibling, 0 replies; 12+ messages in thread
From: Fredrik ÃÂhrström @ 1999-09-30 18:02 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour
1999-09-14 14:08 ` Martin v. Loewis
1999-09-15 9:06 ` Almost got glibc working with no-vtable-thunks, but Fredrik Ãhrström
@ 1999-09-30 18:02 ` Martin v. Loewis
1 sibling, 0 replies; 12+ messages in thread
From: Martin v. Loewis @ 1999-09-30 18:02 UTC (permalink / raw)
To: d92-foh; +Cc: gcc
> /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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour
1999-09-14 6:36 ` Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour Fredrik Ãhrström
1999-09-14 14:08 ` Martin v. Loewis
@ 1999-09-30 18:02 ` Fredrik Ãhrström
1 sibling, 0 replies; 12+ messages in thread
From: Fredrik ÃÂhrström @ 1999-09-30 18:02 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: gcc
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1999-09-30 18:02 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <199909022230.AAA00668@mira.isdn.cs.tu-berlin.de>
1999-09-14 6:36 ` Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour Fredrik Ãhrström
1999-09-14 14:08 ` Martin v. Loewis
1999-09-15 9:06 ` Almost got glibc working with no-vtable-thunks, but Fredrik Ãhrström
1999-09-15 15:05 ` Martin v. Loewis
1999-09-16 3:50 ` Fredrik Ãhrström
1999-09-16 10:37 ` Martin v. Loewis
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
1999-09-30 18:02 ` Troubles with -fno-vtable-thunks recompilation.... Was: Strange C++ behaviour Martin v. Loewis
1999-09-30 18:02 ` Fredrik Ãhrström
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).