This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [3.2/3.3/HEAD] shared libobjc not built


> >gcc configured without explicit --enabled-shared builds shared
> >libraries for libstdc++, libgcj, etc, but not for libobjc (i386-linux)
> >Is this intended? libobjc's configure sets the default to disabled.
> 
>  From <http://gcc.gnu.org/install/configure.html>:
> >--enable-shared[=package[,...]]
> >Build shared versions of libraries, if shared libraries are supported on 
> >the target platform. Unlike GCC 2.95.x and earlier, shared libraries are 
> >enabled by default on all platforms that support shared libraries, except 
> >for libobjc which is built as a static library only by default.
> >If a list of packages is given as an argument, build shared libraries only 
> >for the listed packages. For other packages, only static libraries will be 
> >built. Package names currently recognized in the GCC tree are libgcc (also 
> >known as gcc), libstdc++ (not libstdc++-v3), libffi, zlib, boehm-gc and 
> >libjava. Note that libobjc does not recognize itself by any name, so, if 
> >you list package names in --enable-shared, you will only get static 
> >Objective-C libraries. libf2c and libiberty do not support shared 
> >libraries at all.
>
> So, yes, I think it's intended, but I don't know why.

I don't know either ... I don't remember - maybe a historical leftover ?

I think if shared libraries are supported, libobjc should be built as
shared.  It should definitely be built as shared, why building it
statically ?  A static libobjc is usually more of a problem than a shared
one!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]