Re: static data member problem

Re: static data member problem

[Alexandre Oliva]

Mark E <snowball3@usa.net> writes:

> The program below generates an "undefined reference to 
> container<char>::null_str_c" when STATIC is defined with egcs 
> 1.1 for DJGPP. It seems perfectly legal to me, is the error correct 
> or have I found a bug?

You have found a bug.  I can reproduce it on IRIX 5.2 and SunOS 4.1.3,
but not on other Unix platforms I've got access to.  I believe it is
the same problem that affects platforms that lack ELF weak-symbols:
static data members of template classes have to be explicitly
instantiated on them :-(

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: static data member problem

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > Mark E <snowball3@usa.net> writes:
 >> The program below generates an "undefined reference to 
 >> container<char>::null_str_c" when STATIC is defined with egcs 
 >> 1.1 for DJGPP. It seems perfectly legal to me, is the error correct 
 >> or have I found a bug?

 > You have found a bug.  I can reproduce it on IRIX 5.2 and SunOS 4.1.3,
 > but not on other Unix platforms I've got access to.  I believe it is
 > the same problem that affects platforms that lack ELF weak-symbols:
 > static data members of template classes have to be explicitly
 > instantiated on them :-(

Yes, but it's not a bug.  Them's the facts of life on such targets, unless
you have a clever idea...

Jason

Re: static data member problem

[Alexandre Oliva]

Jason Merrill <jason@cygnus.com> writes:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

>> I believe it is the same problem that affects platforms that lack
>> ELF weak-symbols: static data members of template classes have to
>> be explicitly instantiated on them :-(

> Yes, but it's not a bug.  Them's the facts of life on such targets, unless
> you have a clever idea...

I'm not object-file expert (I'm not even a beginner :-), but, since we 
have collect2 on all platforms (don't we?), couldn't we arrange that
g++ writes some notes in the object files that collect2 can use to
instantiate the missing symbols at link time?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: static data member problem

[Mark E.]

> Mark E <snowball3@usa.net> writes:
> 
> > The program below generates an "undefined reference to 
> > container<char>::null_str_c" when STATIC is defined with egcs 
> > 1.1 for DJGPP. It seems perfectly legal to me, is the error correct or
> > have I found a bug?
> 
> You have found a bug.  I can reproduce it on IRIX 5.2 and SunOS 4.1.3, but

Thanks Alexandre,
I hope it eventually gets fixed. Though from reading the discussion 
on the egcs-bugs list, it doesn't sound like a simple fix to make. 
On the other hand, the problem I submitted appears to be the 
same one that also gives linker errors using STL. And if I can't use 
SGI's STL, there's not much point in using egcs until it does work.

Thanks,
Mark

-- 
Mark E. snowball3@usa.net
http://members.xoom.com/snowball3/

Re: static data member problem

[Alexandre Oliva]

Mark E <snowball3@usa.net> writes:

>> Mark E <snowball3@usa.net> writes:
>> 
>> > The program below generates an "undefined reference to 
>> > container<char>::null_str_c" when STATIC is defined with egcs 
>> > 1.1 for DJGPP. It seems perfectly legal to me, is the error correct or
>> > have I found a bug?
>> 
>> You have found a bug.  I can reproduce it on IRIX 5.2 and SunOS 4.1.3, but

> And if I can't use SGI's STL, there's not much point in using egcs
> until it does work.

Note that you may get it working with -frepo.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: static data member problem

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > Jason Merrill <jason@cygnus.com> writes:
 >>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 >>> I believe it is the same problem that affects platforms that lack
 >>> ELF weak-symbols: static data members of template classes have to
 >>> be explicitly instantiated on them :-(

 >> Yes, but it's not a bug.  Them's the facts of life on such targets, unless
 >> you have a clever idea...

 > I'm not object-file expert (I'm not even a beginner :-), but, since we 
 > have collect2 on all platforms (don't we?), couldn't we arrange that
 > g++ writes some notes in the object files that collect2 can use to
 > instantiate the missing symbols at link time?

That's called -frepo.  We could put the annotations in the object files,
but it would be more work.

Jason

Re: static data member problem

[Mark E.]

> Note that you may get it working with -frepo.

Thanks for the suggestion Alexandre, but -frepo doesn't work 
either. I tried my sample program with mingw32 and it linked just 
fine. Does this support thinking that it's because DJGPP doesn't 
use ELF? I'd also like to point out that the sample program didn't 
link on either when using the -frepo flag.

Thanks for the suggestion,
Mark

-- 
Mark E. snowball3@usa.net
http://members.xoom.com/snowball3/

Re: static data member problem

[Mumit Khan]

On Wed, 23 Sep 1998, Mark E. wrote:

> > Note that you may get it working with -frepo.
> 
> Thanks for the suggestion Alexandre, but -frepo doesn't work 
> either. I tried my sample program with mingw32 and it linked just 
> fine. Does this support thinking that it's because DJGPP doesn't 
> use ELF? I'd also like to point out that the sample program didn't 
> link on either when using the -frepo flag.

DJGPP uses a different executable COFF file format, not PE-COFF that
mingw32, cygwin32, uwin etc use. ELF and PE-COFF are currently the only 
two "good" platforms for g++ templates where everything just works; for
the rest, you do need explicit instantiation and/or -frepo to avoid code
bloat.

I don't enough about djgpp to know what the collect2 issues are and why
-frepo didn't work.

btw, the reason -frepo flag doesn't work on mingw32 is because it is
one of the very platforms where collect2 doesn't work. I partially did
a port for collect2 a long time ago (search egcs list for "mingw32" and
"collect2"), but it was rather a gross hack to get around the fact the
MS runtime doesn't support fork/exec and a few other things.

Regards,
Mumit

Re: static data member problem

[Alexandre Oliva]

Jason Merrill <jason@cygnus.com> writes:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> Jason Merrill <jason@cygnus.com> writes:
>>>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

>>>> I believe it is the same problem that affects platforms that lack
>>>> ELF weak-symbols: static data members of template classes have to
>>>> be explicitly instantiated on them :-(

>>> Yes, but it's not a bug.  Them's the facts of life on such targets, unless
>>> you have a clever idea...

>> I'm not object-file expert (I'm not even a beginner :-), but, since we 
>> have collect2 on all platforms (don't we?), couldn't we arrange that
>> g++ writes some notes in the object files that collect2 can use to
>> instantiate the missing symbols at link time?

> That's called -frepo.  We could put the annotations in the object files,
> but it would be more work.

But it would get egcs more Standard-compliant on those platforms.
Explicitly instantiating template parameters is no fun, and some
people are trying to write portable packages in C++.  Until this
problem is fixed, widely (?) used systems such as SunOS4 and IRIX5
are hardly going to be supported by template-intensive applications.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: static data member problem

[Theodore Papadopoulo]

oliva@dcc.unicamp.br said:
> That's called -frepo.  We could put the annotations in the object
> files,
> but it would be more work.

> But it would get egcs more Standard-compliant on those platforms.
> Explicitly instantiating template parameters is no fun, and some
> people are trying to write portable packages in C++.  Until this
> problem is fixed, widely (?) used systems such as SunOS4 and IRIX5 are
> hardly going to be supported by template-intensive applications. 


	So the beginner's question is: is it possible (well it's 
always possible, I mean is it a good solution) to make -frepo 
used by default (at configure time) for those architectures ??

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: static data member problem

[Alexandre Oliva]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

> 	So the beginner's question is: is it possible (well it's 
> always possible, I mean is it a good solution) to make -frepo 
> used by default (at configure time) for those architectures ??

It certainly is, but it won't solve all the problems.  The first on
that comes to my mind is that -frepo will only work if you compile and 
link in two separate steps.  Moreover, it won't work for libraries.

My idea was more on the line of emulating weak definitions by
generating code for them as if they were members of anonymous
namespaces.  Then, at link time, collect2 could extract the required
pieces of code from the object file, rename the symbols so as to match 
their original names, then link everything together.

I'm not sure it is possible to extract information like that from
object files, though.  Another solution would be to write the assembly
code (text) of the ``weak'' definitions into the object file, in a way
that collect2 could extract it, generate a single assembly file
containing all the weak definitions, assemble it and link it together
with the other object files.

Is any of these approaches possible?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: static data member problem

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > My idea was more on the line of emulating weak definitions by
 > generating code for them as if they were members of anonymous
 > namespaces.  Then, at link time, collect2 could extract the required
 > pieces of code from the object file, rename the symbols so as to match 
 > their original names, then link everything together.

This is actually what IBM does in xlC, more or less, though they don't
extract any code, they just choose one of the definitions and rename it.
Since their linker does garbage collection, the other definitions are
discarded.  Unfortunately, a.out can't support garbage collection any more
than it can support the current ELF model.

 > I'm not sure it is possible to extract information like that from
 > object files, though.  Another solution would be to write the assembly
 > code (text) of the ``weak'' definitions into the object file, in a way
 > that collect2 could extract it, generate a single assembly file
 > containing all the weak definitions, assemble it and link it together
 > with the other object files.

I suppose it might be possible to stick that stuff into the symbol table
along with the debugging info, but that sounds like a nightmare.

In any case, a.out is becoming less and less relevant.

Jason

Re: static data member problem

[Mark E.]

Mumit Khan (khan@xraylith.wisc.edu) wrote:

> DJGPP uses a different executable COFF file format, not PE-COFF that
> mingw32, cygwin32, uwin etc use. ELF and PE-COFF are currently the
> only two "good" platforms for g++ templates where everything just
> works; for the rest, you do need explicit instantiation and/or -frepo
> to avoid code bloat.

I wonder, is it possible to use or adapt the method used in PE-
COFF to instantiate templates to COFF? From looking at the 
specs, the biggest difference between the two seems to be the 
additional informational/OS requirements fields in the PE-COFF 
header so a quick look would make it seem possible.

Mark

-- 
Mark E. snowball3@usa.net
http://members.xoom.com/snowball3/

Re: static data member problem

[Mark E.]

> Alexandre Oliva (oliva@dcc.unicamp.br)
> 
> Another solution would be to write the assembly
> code (text) of the ``weak'' definitions into the object file, in a way
> that collect2 could extract it, generate a single assembly file
> containing all the weak definitions, assemble it and link it together
> with the other object files.
> 

Sounds kind of like the "in the future" paragraph in the gcc 
documentation:

 A future version of g++ will support a hybrid model whereby the 
compiler will emit any instantiations for which the template 
definition is included in the compile, and store template 
definitions and instantiation context information into the object file 
for the rest.

The link wrapper will extract that information as necessary and 
invoke the compiler to produce the remaining instantiations.  The 
linker will then combine duplicate instantiations.

---------------------------------------

At any rate, I sincerely hope something is worked out for those of 
using non-ELF formats.

Mark

-- 
Mark E. snowball3@usa.net
http://members.xoom.com/snowball3/

Re: static data member problem

[Mark E.]

> > Note that you may get it working with -frepo.
 
Here's the output of my sample code using the -frepo flag (sorry in 
advance for the formatting). You'll note that nowhere does it 
mention about reading test2.rpo even though it's generated. For 
some reason, test2.rpo isn't being read.

Is this likely an egcs issue or a DJGPP issue?

C:\DJGPP\PROJECTS\TEST2>gcc -v -frepo -c -o test2.o test2.cpp
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/egcs-291.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)
 c:/djgpp/lib/gcc-lib/djgpp/egcs-291.57/cpp.exe -lang-c++ -v -undef -
D__GNUC__=2
 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -
Dunix -Di386 -DGO32 -DMSDOS -DD
JGPP=2 -DDJGPP_MINOR=2 -D__EXCEPTIONS -D__unix__ -
D__i386__ -D__GO32__ -D__MSDOS
__ -D__DJGPP__=2 -D__DJGPP_MINOR__=2 -
D__EXCEPTIONS -D__unix -D__i386 -D__GO32 -
D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=2 -
Asystem(unix) -Asystem(msdos) -Acpu(i386
) -Amachine(i386) -D__EXCEPTIONS -Ic:/djgpp/include/custom/ 
test2.cpp c:/djgpp/t
mp/cccTZk8e.ii
GNU CPP version egcs-2.91.57 19980901 (egcs-1.1 release) 
(80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 c:/djgpp/include/custom
 c:/djgpp/lang/cxx
 c:/djgpp/lib/gcc-lib/djgpp/egcs-291.57/include
 c:/djgpp/include
End of search list.
 c:/djgpp/lib/gcc-lib/djgpp/egcs-291.57/cc1plus.exe 
c:/djgpp/tmp/cccTZk8e.ii -qu
iet -dumpbase test2.cc -version -frepo -o c:/djgpp/tmp/cciFDCQQ.s
GNU C++ version egcs-2.91.57 19980901 (egcs-1.1 release) 
(djgpp) compiled by GNU
 C version egcs-2.91.57 19980901 (egcs-1.1 release).
 c:/djgpp/bin/as.exe -o test2.o c:/djgpp/tmp/cciFDCQQ.s

C:\DJGPP\PROJECTS\TEST2>gcc -v -frepo -o test2.exe test2.o
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/egcs-291.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)
 c:/djgpp/lib/gcc-lib/djgpp/egcs-291.57/collect2.exe -o test2.exe 
c:/djgpp/lib/c
rt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/egcs-291.57 -Lc:/djgpp/bin -
Lc:/djgpp/lib tes
t2.o -lgcc -lc -lgcc -Tdjgpp.djl
test2.o(.text+0x27):test2.cpp: undefined reference to 
`container<char>::null_str
_c'
collect2: ld terminated with signal 1 [Interrupt X01]


-- 
Mark E. snowball3@usa.net
http://members.xoom.com/snowball3/