Re: liobjc shared supp using libtool

Re: liobjc shared supp using libtool

[Nicola Pero]

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 ?  

Re: liobjc shared supp using libtool

[Ovidiu Predescu]

Your email got stuck into an unexpected mail folder because of a problem in my
.procmailrc file; I only now discovered it.

The constant string flag to the compiler sounds like a very good idea! I'll go
ahead and implement it as soon as possible.

As for the shared library support with libtool, please send me the patches,
I'll apply them. Did FSF receive your copyright assignments yet?

Best regards,
Ovidiu

On Wed, 19 Jul 2000 13:40:03 +0200 (CEST), Nicola Pero <n.pero@mi.flashnet.it> 
wrote:

> 
> 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 ?  
> 
>