discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linking frameworks does not work


From: Wolfgang Lux
Subject: Re: Linking frameworks does not work
Date: Sun, 6 May 2018 14:04:01 +0200


> Am 02.05.2018 um 17:10 schrieb Andreas Höschler <ahoesch@smartsoft.de>:
> 
> Hi Wolfgang,
> 
>>>   [NSString stringByChaining:@"ass" count:3];
>>> 
>>> ...
>>> 
>>>   [pool release];
>>> 
>>>   return NSApplicationMain (argc, argv);
>>> }
>>> 
>>> Is this directly enough?
>> 
>> No.
>> 
>>> The method NSString::stringByChaining:count:] is defined/implemented in my 
>>> SRFoundation framework.
>> 
>> True. But when looking for a reference to resolve the NSString class, the 
>> linker is stubbornly looking for the class definition itself (which is found 
>> in gnustep-base) and not for any categories defined for that class. Indeed 
>> it can be fairly painful to get categories linked from frameworks/libraries 
>> into an executable. You really need a class implementation and not a 
>> category (or a global variable or function) to enforce linking.
> 
> Thanks a lot. I added
> 
>    [SRMailDelivery sendMailFrom:@"asas" to:@"asas" subject:@"asas" 
> body:@"asas" attachmentsAndFilenames:nil];
> 
> to the code and this indeed forced SRFoundation to be linked in. The 
> execption happens now later when trying to call a category method of just 
> another framework. 
> 
> This is indeed painful and annoying and has not always been that way in the 
> past, not on Solaris with GNUstep make and also not on Debian and Kubuntu and 
> definitely not on MacOSX. 

It is indeed painful. However, you might get away by a judicious use of linker 
options. Adding -Wl,--no-as-needed *before* the -l options referring to your 
frameworks should get them included into the executable even without an 
explicit reference to a class (or variable or function) in your framework. 
Interestingly, --no-as-needed is the default for the linker and gcc apparently 
adds an implicit --as-needed option before the -l options. Perhaps this was not 
the case in earlier versions of gcc/Ubuntu.
Incidentally, clang also does not add an implicit --as-needed option, so your 
test should have worked with clang without any extra options.

Wolfgang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]