Re: problem creating a static library

[Danilo José <danilo dot guerrero at deimos-space dot com>]

Hi!
  Thanks for the advise.
  The thing is that I have some problems.
  I suppose that .s file is the .a file
  The thing is that I need to use the .a file, because it is a requirement
of the migration to Mac Os X.

   So I have to use it.

   I found two work arounds but I can not use any of them:

   1)  When building the executable If I include the .o file that contains
the implementation of the method that is undefined, I can build the
executable. But that's not possible because we have to deliver the library
consistent by itself.

   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.

    What is the other way that you told me of doing a workaround, I did not
understand it very well.

>>  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.


    So the thing, is that as far as I have seen. In the compilation of the
gcc 3.1 in Mac_OS_X:

    The symbols appear like this inside the StdError.o , when doing a c++
filt.

         U
gol::ObjAppendList<gol::CalcBinderData*>::ObjAppendList[in-charge](long,
gol::CalcBinderData* const*)

   Inside the ObjAppendListTypes.o

          T
gol::ObjAppendList<gol::CalcBinderData*>::ObjAppendList[in-charge](long,
gol::CalcBinderData* const*)

    Inside the library libgol.a that I am trying to build like this :

U gol::ObjAppendList<gol::CalcBinderData*>::ObjAppendList[in-charge](long,
gol::CalcBinderData* const*)
00011234 T
gol::ObjAppendList<gol::CalcBinderData*>::ObjAppendList[in-charge](long,
gol::CalcBinderData* const*)

     With these results of nm, the executable is possible to be linked.

     In the gcc 2.95.2 (the version macintosh calls 937.2) with the same
compiling flags.

      I get this:
     In StdError.o:
         gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long, gol
*const *)

    In ObjAppendListTypes.o:

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

    The strange thing, it appears a reference to it inside CalcParser.tab.o,
that does not appear with the gcc 3.1:

         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)

    Inside the library libgol.a we have this:

         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
         U gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)
00000958 S gol::ObjAppendList<gol::CalcBinderData *>::ObjAppendList(long,
gol *const *)

      With this configuration the executable does not build.











> 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]

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


> 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.
>