Re: Linker shows "has different visibility" warning (2nd)
Re: Linker shows "has different visibility" warning (2nd)
- Subject: Re: Linker shows "has different visibility" warning (2nd)
- From: "Daniel Lord" <email@hidden>
- Date: Fri, 21 Mar 2008 08:23:54 -0700
On 3/21/08,
Mark Taylor <
email@hidden> wrote:
For the benefit of anyone in the future who finds this thread in the
archives like I did, the resolution in my case was to make sure the
GCC "Inline Methods Hidden" flag (aka
"GCC_INLINES_ARE_PRIVATE_EXTERN") for my target matched the setting
for the library I was linking in. Changing that flag made the
thousands of warnings disappear. "Symbols Hidden by Default" aka
"GCC_SYMBOLS_PRIVATE_EXTERN" is also worth checking.
- Mark
Mark,
Understood, but that raises more questions.
So that means, that all libraries linked must have been compiled with the same value or the warnings will persist no?
How is that under our control if we are linking in several libraries with opaque build architectures like bjam & jam (refering to Boost specifically) where we cannot find those kind flags in the disparate build structures? Just getting a universal 32-bit build out of Boost is not always straaightforward
Boost gives me no end of pain in this area between that and having 10 versions of each library, each with slightly different symbol content.
Daniel
On Jan 12, 2008, at 3:01 AM, Dieter Oberkofler wrote:
> Thank you for all the replies.
> I'm starting to understand but there is still one loose end: When
> switching from XCode 2.4.1 on 10.4 to XCode 2.5 on 10.5 all build
> scripts remained the same (the visibility flags in the different 3rd
> party libraries and my own build scripts remained unchanged) but
> before there where no warning and now I have several thousand
> warning in a single link. The gcc version stayed the same, so where
> does this come from?
> Thank you,
> Dieter
>
> On 11.01.2008, at 18:44, Jerry wrote:
>
>> The solution seems to compile all the libraries you use with -
>> fvisibility=default or decorate all your source code with
>> visibility attributes, but this is no good if you're relying on
>> third-party libraries for which you don't have the source. I've
>> managed to get my warnings down to 10000 on every build, but build
>> time is doubled by the time it takes to print out all those
>> messages. My actual solution is to revert to Tiger for development,
>> which also solves a host of other linking problems, such as those
>> associated with using libcurl, and as a bonus I don't have kernel
>> panics every half hour any more.
>>
>> Jerry
>>
>> On 11 Jan 2008, at 16:40, Alexander von Below wrote:
>>
>>> Yes, it has been a topic on this list ... but a search of the
>>> archives does not even yield my own posts about it :-/
>>>
>>> So this should answer your questions:
>>>
>>> http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html
>>>
>>> HTH
>>>
>>> Alex
>>>
>>> Am 11.01.2008 um 16:43 schrieb Dieter Oberkofler:
>>>
>>>> After upgrading from XCode 2.4.1 to 2.5 running on Leopard the
>>>> linker shows me thousands of "has different visibility" warnings.
>>>> (ld: warning __ZN13PWR_CStringRWC2ERKS_.eh has different
>>>> visibility (1) in /MyDev/LJS_DEV/app/trunk_build/debug/
>>>> libLJS_SQL_LIB.a(costcentre.o) and (2) in /MyDev/LJS_DEV/app/
>>>> trunk/xvt/mac/lib/libXVTPWRd.a(CTdiPackage.o))
>>>> Has someone already solved this one?
>>>> Thank you
>>>> Dieter
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Xcode-users mailing list (email@hidden)
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>>
>>> This email sent to email@hidden
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden