On Tue, 11 Apr 2000, Ossama Othman wrote:
> Hi Kevin,
>
> On Tue, Apr 11, 2000 at 02:43:23AM -0400, Kevin Atkinson wrote:
> > On Mon, 10 Apr 2000, Ossama Othman wrote:
> > > Right. I don't have access to all of the platforms supported by libtool's
> > > C library support so I wasn't able to configurations for all of the
> > > platforms. Any contributions would be more than welcome.
> >
> > What can I do. Shouldn't it work about the same when g++ is the C++
> > compiler. What type of information can I send you or what can I do
> > without having intimate knowledge of how libtool works.
>
> Yes, but the way things are setup right now g++ has to be configured
> for each platform. I forget why I did that. In any case, I can
> probably add a default g++ configuration, such as what is done for gcc
> when building C shared libraries. That should help you out.
Yes it would. What information can I send you for supporting other C++
compilers.
> > > I'm a bit confused here. What does compiling libtstdc++ have to do with
> > > libtool? The gcc/libstdc++ distribution has its own support for compiling
> > > that library as a shared one.
> >
> > Because libstdc++ is compiled ONLY as a static library. When I tried
> > creating a C++ shared library it tried to put the static library into the
> > shared library which failed miserably as the code does was not compiled
> > with PIC support. At least that is what I think happened.
>
> That sounds about right. Libtool doesn't try to do too much magic,
> nor should it, IMO. If the g++ installation doesn't support C++ shared
> libraries then neither will libtool.
Here is the lowdown. At least on solaris.
g++ -shared -fPIC <file>
does not work but
g++ -shared -fPIC <file> -nostdlib
DOES.
Reason. Libstdc++ was not compiled as a shared library OR with -fPIC.
I would like libstdc++ to somehow avoid linking in the standard libraries
BUT included them in the dependency list so that a C program linking to the
library will include the necessary static library when creating the final
program.
> > > Try using g++'s -nostdlib flag, or one of the other related ones when
> > > configuring your library. If I set things up properly, libtool should
> > > use that flag when configuring the C++ support, and avoid linking in
> > > libstdc++. Note that -nostdlib will also prevent the start files from
> > > being linked in.
> >
> > I will try that. How about a more generic solution.
>
> Do you mean that you would like libtool to have the ability to not
> link in certain libraries? I suppose we could add an option to do
> that but I don't think that is very portable since I'm not sure if all
> C++ compilers provide a flag that prevents linking in certain system
> libraries, which the "generic" solution would need.
Maybe but it would be nice that if the C++ compiler DOES support it there
is a generic libtool option for it. If not it will report an error or
such.
> Not much I guess. I'm just used to going in the other direction,
> i.e. writing C++ programs that link in C libraries. Linking C++
> libraries into a C program puts a real limit on what you can do in
> terms of object oriented design, which I need. However, you are
> entirely correct that extern "C" functions will certainly work with C
> programs. I just happen not to write C programs. :-)
I don't either but I want my library to be able to be used by C programs.
It is not really a C++ specific library. It is more of a library that
provides a service which happens to be written in C++ instead of C.
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
