408959 - Lots of warnings when linking Camino (especially static) built with Xcode 3.0 gcc 4.0

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Mark Mentovai]

While linking CaminoStaticApp, there are 7,529 lines like this:

ld: warning nsIObserver::GetIID()::iid       has different visibility (2) in ../dist/lib/libembed_base_s.a(nsEmbedAPI.o) and (1) in /lizard/1.8/build/camino-static/camino/build/Camino.build/Deployment/CaminoStaticApp.build/Objects-normal/i386/CHBrowserService.o
ld: warning nsIStringBundleService::GetIID()::iid       has different visibility (2) in ../dist/lib/libembed_base_s.a(nsEmbedAPI.o) and (1) in /lizard/1.8/build/camino-static/camino/build/Camino.build/Deployment/CaminoStaticApp.build/Objects-normal/i386/SecurityDialogs.o
ld: warning nsIObserver::GetIID()      has different visibility (2) in ../dist/lib/libembed_base_s.a(nsEmbedAPI.o) and (1) in /lizard/1.8/build/camino-static/camino/build/Camino.build/Deployment/CaminoStaticApp.build/Objects-normal/i386/CHBrowserService.o

This occurs when building the 1.8 branch using gcc 4.0 and the ld supplied in the Xcode 3.0 toolchain.  This new ld produces warnings when symbols with the same name have different visibilities.  This is documented in the Xcode 3.0 ld release notes - Apple says that they need a better warning.

http://developer.apple.com/releasenotes/DeveloperTools/RN-Id/index.html#//apple_ref/doc/uid/TP40006506-DontLinkElementID_2, "Need better warning about mixed visibilities."

This problem affects us because the non-Xcode-driven portion of the build on the 1.8 branch is done without enabling hidden-visibility support in the compiler.  The Xcode-driven Camino build is done with -fvisibility=hidden -fvisibility-inlines-hidden when using gcc 4.0.  gcc 3.3 doesn't support hidden visibility, so these warnings aren't seen during a gcc 3.3 build, such as the normal ppc build.  They are seen during a normal x86 build.

I've got a tricky way to push visibility support into the core build that doesn't involve any core changes at all.  Unfortunately, flipping that on results in the same visibility warnings as above (although substantially fewer) being produced during the final CaminoStatic link regarding transformiix code.    Based on a quick look, it seems like some header that transformiix depends on is doing something it shouldn't to the visibility state.  I don't know if I'll be able to fix that part without touching things outside of camino.

Comment 1

[Mark Mentovai]

For reference, there are only 50 such warnings about transformiix in my modified CaminoStaticApp build.

Unmodified CaminoApp (nonstatic) builds also produce warnings similar to the above, but far fewer than the 7,529 in CaminoStatic.

Hidden-visibility isn't enabled in core on the 1.8 branch because the configure script contains a couple of bugs regarding compiler hidden-visibility support detection on the Mac.

Comment 2

[Mark Mentovai]

Attachment: Force hidden-visibility support via the mozconfig

This is pretty tricky.

We need to disable xpcom-obsolete to do this because libxpcom_compat depends on some MoreFilesX stuff (FSGetParentRef and FSRefValid) in libxpcom_core that winds up with hidden visibility.  I could fix up the visibility, but it doesn't seem worth it given that we don't care about libxpcom_compat and the visibility change only causes an intermediate link failure for mozilla-bin that we'd otherwise be able to ignore.

We need to disable profilesharing because it brings in ipcd which depends on nsIDHashKey::HashKey(nsID const*), a similar my-visibility-changed-or-I-was-otherwise-dead-stripped symbol.  We don't care about it and we don't use it, so I'm killing it.  profilesharing is already off on the Camino trunk.

The visibility change and the elimination of code we don't care about saves us some space.  I count 412kB of savings in an x86-only dmg.  Quick, put it in a CD before rates fall any further!

Comment 3

[Mark Mentovai]

We need bug 408935 to keep static builds from breaking when we stop building xpcom-obsolete.

Bug 409027 is for the transformiix problem I mentioned at the end of comment 0.

I have patches on both bugs, but they'll need branch approval.

Comment 4

[Mark Mentovai]

This exposes bug 409066 during a non-static build.  There's a patch on that bug.

Comment 5

[Mark Mentovai]

Comment on attachment 293880 [details] [diff] [review]
Force hidden-visibility support via the mozconfig

All of the dependencies landed.  This trims some fat and cleans up all of the visibility warnings presented by Xcode 3's ld.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 293880 [details] [diff] [review]
Force hidden-visibility support via the mozconfig

Nice!  I get 0 of these fun warnings now building static Uni (after a distclean) and only 50 non-static; r=ardissone.

Sorry it took me so long to get to this; please save 7500+ lines of space in our tinderbox logs at your earliest convenience ;)

Comment 7

[Mark Mentovai]

What are the 50 warnings about?  Shouldn't be visibility.  Something else?

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: log snippet

Yes, visibility.  Stuff from libunicharutil_s.a and libprofdirserviceprovider_s.a (and I see the same 50 on trunk non-static, too, though I haven't distcleaned it recently).

Comment 9

[Mark Mentovai]

Checked in on the MOZILLA_1_8_BRANCH for 1.6b1.

I'm starting a clean 1.8 branch nonstatic build to check on comment 8, and we can do a new bug to fix it if needed.

Comment 10

[Mark Mentovai]

I've diagnosed the comment 6 thread, it's now in bug 409640.

This bug's all closed up now.

Comment 11

[Mark Mentovai]

Not surprisingly, this looks like a Ts win on x86.  There should be no impact on ppc (unless we switch to gcc 4 and correspondingly set 10.3.9 as our minimum instead of 10.3).