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


> > > 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!
> 
> I don't actually use, ObjC, so I don't really know about it But I always 
> build with --enable-shared, just to be sure :-)
> Maybe some Knowledgeable Person here can aswer that...

Hmmm ... I suspected to have originally wrote/submitted the lines

# Disable shared libs by default
AC_DISABLE_SHARED

of libobjc/configure.in myself; now checking the CVS and ChangeLog entries
confirmed it.  I don't remember any reason why I wanted to disable shared
libs, and I think that the reason of disabling shared libs by default was
just that, being the switch to build libobjc as shared an experimental
change to libobjc at the time, I was being conservative.

Since we have tested this a lot now (more than two years of testing is
enough I presume :-), I don't see any reason to keep shared libs disabled
by default now, if shared libs are available on the platform.  It's stupid
and it just makes configuring GCC for Objective-C more troublesome.

Nor do I see any reason to keep the libobjc building and configuring
process different from the one used by other shared libs included in GCC.


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