TCLUG Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TCLUG-DEVEL:124] C++/C linking problems



"Eric M. Hopper" wrote:

> On Thu, Mar 02, 2000 at 03:44:11PM -0600, Scott J. Pekarek wrote:
> >
> > I recognize most of the symbols as various instantiations of some of
> > my template functions - and thus I know the pain is self inflicted.
> > It appears some of my templates are being instantiated in my shared
> > libraries and some are not.  As a note this is code (templates) that
> > do compile on Digital Unix, HP-UX and Solaris - but we are using the
> > proprietary compilers on those platforms (and various platform
> > specific #ifdef, #pragma methodologies to go with each compiler).
> >
> > I am flying by the seat of my pants on Linux here but from what I
> > read I am compiling my shared libraries with "-shared -frepo".
> > This looks like the "preferred" scheme with egcs-1.1.2 yes/no?
>
>         I think it's -shared and -fPIC.
>
> > I thought I had gone through the code and made sure that everyplace we
> > had a template instantiation that the definition was there (the
> > template.C file was included by the already included template.h file).
> > I don't have to do anything to tell the linker to pick up all these
> > *.rpo files do I?
>
>         *.rpo?  That seems like an odd extension.  The common extension
> for .o files destined to eventually be stuck into a .so library is .s.o.
> And yes, you do need to do something.  You need to use gcc with the
> -shared option to link all of the .s.o files into a .so file.  Then
> things that want to use symbols out of the .so file, need to link it in
> as a library.

I thought it odd as well - and I may be doing it wrong but when I use
the -frepo option they show up for every object file which instantiates
a template - like foo.o and foo.rpo.  I can't seem to find it now but
I thought I read some where that "collect2" gathered these things
up as part of the link phase and made sure that the templates where
properly instantiated in the executable- which does not seem to be
happening either.

At any rate I found a couple cygnus threads on -frepo and it turns
out a number of people have reported various problems with -frepo.
There is a guy from cygnus (Martin) who recommends not using -frepo.
He says to use no template specific options, that gcc will figure it out
and -frepo has bugs AND the documentation maybe should be updated
to reflect this.  I tried and ended up with a whole new set of problems.  So then
I downloaded and upgraded my compiler to 2.95.2 and am working on
that no - with no -frepo option.  So far it looks better.

I don't believe the -fpic is necessary for building shared libraries
but it shouldn't hurt.  I am a minimalist if I can get away with it.

Thanks for the info guys.

sjp