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]

Re: liobjc shared supp using libtool



Hi Ovidiu !
How was your travel to Sweden ?  :-)

Perhaps - do you have some time now to have a look at the patches so that
we can manage to merge the shared lib support into libobjc's gcc?  I have
been using it for quite some months and it just works - though the issues,
if any, will probably more about portability.  My copyright assignment has
also been registered quite some time ago. 

There is still the unresolved question about NXConstantString - I was
suggested on the gcc list to make the NXConstantString class from libobjc
weak, which is probably going to take me quite some time, so it doesn't
look like a good solution (unless someone else has experience and/or time
to do it).  [Anyway, sooner or later I need to learn something about gcc
internals so we can help supporting objective-C, but it seems too messy a
thing to start with.]

But - in a recent mail from Richard Frith-Macdonald a nice idea was
exposed.  He was suggesting to add a command line option to gcc to change
the name of the class used for objective-c constant strings.  This looks
like very very nice to me.  We would leave libobjc's NXConstantString as
it is; we would rename gnustep's constant string class to
NSConstantString, and then whenever we compile with GNUstep base library
we add the command line option to gcc to tell him to assemble the constant
strings as NSConstantString rather than NXConstantString (This is very
easy since we just need to add the flag in the gnustep-make package).  The
solution would be very clean, straightforward, secure, and reusable by
other projects and/or on platforms where the NXConstantString linking
trick/problem never worked.  Actually, it just seems an elegant
simplification of the whole stuff (which will incidentally make it easier
to understand and maintain). 

Any comments on this solution ?  
Should we bother implementing it ?  


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