problem creating a static library

problem creating a static library

[Danilo José]

Hello I am having a problem creating a static library with gcc 2.95.2. In a
MacOSX system.

 I have compiled  the objects without any problem. I create the static
library using the ar command.

 The thing is that when I use the library to build an executable it gives me
some errors of undefined symbols.

  But if I use directly the objects the executable works correctly.


++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./..
/include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
ar crs -crv  ./../lib/Mac_OS_10/libgol.a String.o StdError.o InputStream.o
JulianDate.o
ser.tab.o CalcScanner.tab.o lex.Calc.o ObjAppendListTypes.o
r - String.o
r - StdError.o
r - InputStream.o
r - JulianDate.o
r - RawBuffer.o
r - Args.o
r - Statistic.o
r - CalcParser.tab.o
r - CalcScanner.tab.o
r - lex.Calc.o
r - ObjAppendListTypes.o
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -o calc_test String.o StdError.o InputStream.o JulianDate.o RawBuffer.o
Args.o Stat
b.o lex.Calc.o ObjAppendListTypes.o
 CalcTest.o -L./../lib/Mac_OS_10 -lgol -L/usr/lib -
g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  -I./.
./include -
g++ -o calc_test_bind
CalcTestBind.o -L./../lib/Mac_OS_10 -lgol -L/usr/lib -lstdc++ -lm
/usr/bin/ld: Undefined symbols:
___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1
___Q23golt13ObjAppendList1ZblPCb
___ls__Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDataRCPB1
___ls__Q23golt13ObjAppendList1ZbRCb
___Q23golt13ObjAppendList1ZPQ23gol8CalcNodelPCPB1
___Q23golt13ObjAppendList1ZPvlPCPv
___Q23golt13ObjAppendList1ZcRCB0
___Q23golt13ObjAppendList1ZclPCc
___as__Q23golt13ObjAppendList1ZcRCB0
___ls__Q23golt13ObjAppendList1ZPQ23gol8CalcNodeRCPB1
___ls__Q23golt13ObjAppendList1ZPvRCPv
_append__Q23golt13ObjAppendList1ZclPCc
_reverse__Q23golt13ObjAppendList1ZPQ23gol8CalcNode
make: *** [calc_test_bind] Error 1


So as you can see when building calc_test, there is no problem because it
uses the objects directly, but when using the library it fails.

   I have checked the library with nm and this is what appears:

nm ../lib/Mac_OS_10/libgol.a | grep
___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1 | c++filt
         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
00000d30 S gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)


nm ObjAppendListTypes.o | grep
___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1 | c++filt

00000d30 S gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)

   ObjAppendListTypes.C is a file that has all the instantiations of the
templates needed by the code:
   Like this:

namespace gol
{

template class ObjAppendList<char>;
template class ObjAppendList<unsigned char>;
template class ObjAppendList<signed char>;
template class ObjAppendList<short>;
template class ObjAppendList<unsigned short>;
template class ObjAppendList<long>;
template class ObjAppendList<unsigned long>;
template class ObjAppendList<long long>;
template class ObjAppendList<unsigned long long>;
template class ObjAppendList<float>;
template class ObjAppendList<double>;
template class ObjAppendList<String>;
template class ObjAppendList<const char*>;
template class ObjAppendList<int>;
template class ObjAppendList<bool>;

template class ObjAppendList<void *>;

template class ObjAppendListP<stringstream>;
template class ObjAppendList<stringstream*>;

template class ObjAppendListP<String>;
template class ObjAppendList<String*>;

template class ObjAppendListP<JulianDate>;
template class ObjAppendList<JulianDate*>;

template class ObjAppendList<RawBuffer *>;
template class ObjAppendListP<RawBuffer>;

template class ObjAppendList<CalcNode *>;
template class ObjAppendListP<CalcNode>;

template class ObjAppendList<CalcBinder *>;
template class ObjAppendListP<CalcBinder>;

template class ObjAppendList<CalcBinderData *>;
template class ObjAppendListP<CalcBinderData>;

} // namespace gol
#endif

   The templates definition are in one .h file.

Re: problem creating a static library

[Mike Stump]

On Sep 29, 2004, at 10:59 AM, Danilo José wrote:
> Hello I am having a problem creating a static library with gcc 2.95.2. 
> In a
> MacOSX system.

> g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates  
> -I./..
> /include -

First, 2.95 is old...  You'll get better milage out of newer 
compilers...

Second -frepo didn't work with apple provided g++ compiler for a while, 
so mixing the two will lead to heartache.  Second, using -frepo across 
a .a file need not work so well.

Running with -v, and seeing if collect2 runs will tell you if -repo is 
going to work at all.  If it does, it will, if not, it won't.

 From there, you can examine the .rpo files and see if and where the 
missing symbols are able to be defined.  If you flip them by hand 
(useful in the case collect2 isn't going to work, or you don't want to 
let the linker see the object files by hiding them in a .a file), you 
should be able to instantiate all the missing symbols.  Kinda gross, 
but you asked.

I'd say, remove -frepo, remove -fno-implicit-templates, use gcc-3.1, or 
gcc-3.3 from apple, and presto, everything should just work.

Re: problem creating a static library

[Danilo José]

yes, well, I was doing tests trying new flags.

   This problem, started to happen before using any of those flags.

   In fact I am using the version of the 2.95.2 gcc compiler that apple has,
the gcc-937.2

   My workmate is telling me that maybe is because the flags of compilations
of the objects.

   It is happening something really strange.

   I see in the library three references to the method that it says it is
undefined.
nm ../lib/Mac_OS_10/libgol.a | grep
___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1 | c++filt
         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
00000d30 S gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)


nm ObjAppendListTypes.o | grep
___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1 | c++filt

00000d30 S gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)

nm StdError.o | grep
___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1 | c++filt
         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)

I do not find any reference inside StdError.o to ObjAppendlist, I do not
know how is it calling it, because therer isn´t any call.



----- Original Message ----- 
From: "Mike Stump" <mrs@apple.com>
To: "Danilo José" <danilo.guerrero@deimos-space.com>
Cc: <gcc@gcc.gnu.org>
Sent: Wednesday, September 29, 2004 9:24 PM
Subject: Re: problem creating a static library


> On Sep 29, 2004, at 10:59 AM, Danilo José wrote:
> > Hello I am having a problem creating a static library with gcc 2.95.2.
> > In a
> > MacOSX system.
>
> > g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates
> > -I./..
> > /include -
>
> First, 2.95 is old...  You'll get better milage out of newer
> compilers...
>
> Second -frepo didn't work with apple provided g++ compiler for a while,
> so mixing the two will lead to heartache.  Second, using -frepo across
> a .a file need not work so well.
>
> Running with -v, and seeing if collect2 runs will tell you if -repo is
> going to work at all.  If it does, it will, if not, it won't.
>
>  From there, you can examine the .rpo files and see if and where the
> missing symbols are able to be defined.  If you flip them by hand
> (useful in the case collect2 isn't going to work, or you don't want to
> let the linker see the object files by hiding them in a .a file), you
> should be able to instantiate all the missing symbols.  Kinda gross,
> but you asked.
>
> I'd say, remove -frepo, remove -fno-implicit-templates, use gcc-3.1, or
> gcc-3.3 from apple, and presto, everything should just work.
>

Re: problem creating a static library

[Danilo José]

I forgot to say, We are doing this in 2.95.2 because we have as requirement
to work in that version and in the 3.1 version and above.

   The thing is that in the 3.1 version works without any problem. Without
any strange flag of compilation.

  Thanks a lot!
  Danilo
----- Original Message ----- 
From: "Mike Stump" <mrs@apple.com>
To: "Danilo José" <danilo.guerrero@deimos-space.com>
Cc: <gcc@gcc.gnu.org>
Sent: Wednesday, September 29, 2004 9:24 PM
Subject: Re: problem creating a static library


> On Sep 29, 2004, at 10:59 AM, Danilo José wrote:
> > Hello I am having a problem creating a static library with gcc 2.95.2.
> > In a
> > MacOSX system.
>
> > g++ -c -DMacintosh -O2 -fvtable-thunks -frepo -fno-implicit-templates
> > -I./..
> > /include -
>
> First, 2.95 is old...  You'll get better milage out of newer
> compilers...
>
> Second -frepo didn't work with apple provided g++ compiler for a while,
> so mixing the two will lead to heartache.  Second, using -frepo across
> a .a file need not work so well.
>
> Running with -v, and seeing if collect2 runs will tell you if -repo is
> going to work at all.  If it does, it will, if not, it won't.
>
>  From there, you can examine the .rpo files and see if and where the
> missing symbols are able to be defined.  If you flip them by hand
> (useful in the case collect2 isn't going to work, or you don't want to
> let the linker see the object files by hiding them in a .a file), you
> should be able to instantiate all the missing symbols.  Kinda gross,
> but you asked.
>
> I'd say, remove -frepo, remove -fno-implicit-templates, use gcc-3.1, or
> gcc-3.3 from apple, and presto, everything should just work.
>

Re: problem creating a static library

[Mike Stump]

On Sep 30, 2004, at 3:56 AM, Danilo José wrote:
>    It is happening something really strange.

Ah, I don't know why you didn't include that information in the first 
place, I could have told you exactly what happened and why.

In the .s file for the file contains the definition ('S'), you will 
find the word notoc, or no_toc, this is a bug.  If that is removed, 
this will work as expected.  The work around, is to not use a .a file, 
or to put a symbol in that file that is referenced by something that is 
in the program.[1]

1 - This depends upon the symbol names being the same between the 
undefined and the defined, after you remove c++filt.  It has been known 
to happen that two differrent spellings are mapped to the same 
demangled name, thus leading to confusion.  I doubt this would be the 
case in this instance.

Re: problem creating a static library

[Danilo José]

Hi!

  I have tested to do the thing you recommended me to
 do the ld -r *.o -o new.o

  Then I have done the library libgol.a using the new.o.

  And what happens is that I get still 4 undefined symbols:

 ___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1
___Q23golt13ObjAppendList1ZblPCb
___ls__Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDataRCPB1
___ls__Q23golt13ObjAppendList1ZbRCb

  When I apply the c++filt to them, it gets me the next output.

  0005169c s gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
  0005177c s gol::ObjAppendList<bool>::ObjAppendList(long, bool const *)
  00051484 s gol::ObjAppendList<gol::CalcBinderData *>::operator<<(gol
*const &)
  000515b4 s gol::ObjAppendList<bool>::operator<<(bool const &)

  But the others undefined symbols have disappeared.
  But I can't still do the executable.

  The .s files I do not think it will be a good approach, because I need to
deliver this makefile to build the libgol.a, so others could use it.

  As far as I know the problem with this is that it has the flag 's' if it
were 'S' it would work. So is there any way to get the 'S' flag, with a
makefile.


----- Original Message ----- 
From: "Mike Stump" <mrs@apple.com>
To: "Danilo José" <danilo.guerrero@deimos-space.com>
Cc: <gcc@gcc.gnu.org>
Sent: Friday, October 01, 2004 12:00 AM
Subject: Re: problem creating a static library


> On Sep 30, 2004, at 1:39 PM, Danilo José wrote:
> >   I suppose that .s file is the .a file
>
> .s is the assembly version of the file.  See man gcc under -save-temps.
>
> >   The thing is that I need to use the .a file, because it is a
> > requirement
> > of the migration to Mac Os X.
>
> Ok, another solution would be ld -r *.o -o new.o and put new.o in the
> .a file.  This might be the easiest to get working for you, now that I
> think of it.
>
> >    2)  I think the problems come because StdError.o does has undefined
> > that
> > method. Because if I include in the code of the StdError.c the template
> > instantiation that is not found, it does not have any problem to
> > compile.
> > But I can not do this because I can not duplicate the code, because
> > that
> > file is already compiled in another object.
>
> I don't know what you mean by cannot duplicate code.  template
> instantiation doesn't duplicate code[1].
>
> >     What is the other way that you told me of doing a workaround, I
> > did not
> > understand it very well.
>
> Remove the string notoc (or no_toc) and the extra , from the .s files
> before assembling.
>
>
> 1 - size a.out numbers remain the same, the summation of all the .o
> files appears larger than the a.out numbers.
>

Re: problem creating a static library

[Mike Stump]

On Sep 30, 2004, at 5:12 PM, Danilo José wrote:
>   And what happens is that I get still 4 undefined symbols:
>
>  ___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1
> ___Q23golt13ObjAppendList1ZblPCb
> ___ls__Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDataRCPB1
> ___ls__Q23golt13ObjAppendList1ZbRCb

:-(

>   The .s files I do not think it will be a good approach, because I 
> need to
> deliver this makefile to build the libgol.a, so others could use it.

You misunderstand.  You can do

gcc foo.c -S; sed 's/notoc,//' <foo.s >foo1.s; gcc foo1.s -o foo.o

if you wanted in the makefile, not the mot pleasant of things to do, 
but not that hard either.

>   As far as I know the problem with this is that it has the flag 's' 
> if it
> were 'S' it would work. So is there any way to get the 'S' flag, with a
> makefile.

-fexport-coalesced with the 3.3 compiler, if you had to do this with 
the gcc2 compiler, sed 's/private_extern/globl/'...  :-(

Re: problem creating a static library

[Danilo José]

> -fexport-coalesced with the 3.3 compiler, if you had to do this with
> the gcc2 compiler, sed 's/private_extern/globl/'...  :-(

could you explain me a little more how to do that last line?
  I have not understood this exactly what should I do here?
  Sorry my level of unix is not very good.
 I must do it with the gcc2 compiler.
 Thanks a lot


----- Original Message ----- 
From: "Mike Stump" <mrs@apple.com>
To: "Danilo José" <danilo.guerrero@deimos-space.com>
Cc: <gcc@gcc.gnu.org>
Sent: Friday, October 01, 2004 2:35 AM
Subject: Re: problem creating a static library


> On Sep 30, 2004, at 5:12 PM, Danilo José wrote:
> >   And what happens is that I get still 4 undefined symbols:
> >
> >  ___Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDatalPCPB1
> > ___Q23golt13ObjAppendList1ZblPCb
> > ___ls__Q23golt13ObjAppendList1ZPQ23gol14CalcBinderDataRCPB1
> > ___ls__Q23golt13ObjAppendList1ZbRCb
>
> :-(
>
> >   The .s files I do not think it will be a good approach, because I
> > need to
> > deliver this makefile to build the libgol.a, so others could use it.
>
> You misunderstand.  You can do
>
> gcc foo.c -S; sed 's/notoc,//' <foo.s >foo1.s; gcc foo1.s -o foo.o
>
> if you wanted in the makefile, not the mot pleasant of things to do,
> but not that hard either.
>
> >   As far as I know the problem with this is that it has the flag 's'
> > if it
> > were 'S' it would work. So is there any way to get the 'S' flag, with a
> > makefile.
>
> -fexport-coalesced with the 3.3 compiler, if you had to do this with
> the gcc2 compiler, sed 's/private_extern/globl/'...  :-(
>

Re: problem creating a static library

[Mike Stump]

On Sep 30, 2004, at 6:05 PM, Danilo José wrote:
>> -fexport-coalesced with the 3.3 compiler, if you had to do this with
>> the gcc2 compiler, sed 's/private_extern/globl/'...  :-(
>
> could you explain me a little more how to do that last line?
>   I have not understood this exactly what should I do here?
>   Sorry my level of unix is not very good.

>> gcc foo.c -S; sed 's/notoc,//' <foo.s >foo1.s; gcc foo1.s -o foo.o

Combining the two, we get:

gcc foo.c -S; sed 's/private_extern/globl/' <foo.s >foo1.s; gcc foo1.s 
-o foo.o

Further help with basic makefiles and basic unix commands are well 
beyond the scope of this list...

Re: problem creating a static library

[Danilo José]

Thank you very much.

  I have done several tests with the things that you have purposed me. But I
still have the same results.

  I do not know why, but the further I get is with the ld -r *.o new.o-

  when doing this it gives me a lot of problems when compiling the object.
  sed 's/private_extern/globl/'

  When doing the
  's/,no_toc//'
  I think is like this because notoc is not found, and no_toc yes with a
comma before.
  It gets as far as if I were using the ld -r *.o -o new.o.

   So i get the same 4 undefined symbols.

   My boss is tellign me to test with machine dependant flags. The thing is
that in the same Mac OS X works with the 3.1 version of g++ but now with the
2.95.2

    So I do not know what to do, because the machine is the same.

    I have seen that the libgcc.a is not in the 2.95.2 gcc directory only in
the 3.1 directory.  Is that a problem for this. Sorry but I am really
worried about this problem.


    Thanks in advance!
    Danilo

----- Original Message ----- 
From: "Mike Stump" <mrs@apple.com>
To: "Danilo José" <danilo.guerrero@deimos-space.com>
Cc: <gcc@gcc.gnu.org>
Sent: Friday, October 01, 2004 3:15 AM
Subject: Re: problem creating a static library


> On Sep 30, 2004, at 6:05 PM, Danilo José wrote:
> >> -fexport-coalesced with the 3.3 compiler, if you had to do this with
> >> the gcc2 compiler, sed 's/private_extern/globl/'...  :-(
> >
> > could you explain me a little more how to do that last line?
> >   I have not understood this exactly what should I do here?
> >   Sorry my level of unix is not very good.
>
> >> gcc foo.c -S; sed 's/notoc,//' <foo.s >foo1.s; gcc foo1.s -o foo.o
>
> Combining the two, we get:
>
> gcc foo.c -S; sed 's/private_extern/globl/' <foo.s >foo1.s; gcc foo1.s
> -o foo.o
>
> Further help with basic makefiles and basic unix commands are well
> beyond the scope of this list...
>

Re: problem creating a static library

[Phil Edwards]

On Fri, Oct 01, 2004 at 04:32:28AM +0200, Danilo Jos? wrote:
> Thank you very much.
> 
>   I have done several tests with the things that you have purposed me. But I
> still have the same results.
> 
>   I do not know why, but the further I get is with the ld -r *.o new.o-

This is completely off-topic for this list.  Please continue this
discussion in private email.

-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen