352451 - Console spew related to RSS

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

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

This is new spew related to the RSS landing.  Stuart said it's harmless and perhaps we just need to change the way the prefs link(?)  This is apparently the only case where a prefPane and part of the app share the same bit of whatever....

Sep 12 17:55:47 Krak-des-Chevaliers /Applications/Internet/Camino.app/Contents/MacOS/Camino: objc: Both /Applications/Internet/Camino.app/Contents/MacOS/Camino and /Applications/Internet/Camino.app/Contents/PreferencePanes/Navigation.prefPane/Contents/MacOS/Navigation have implementations of class AppListMenuFactory.
Sep 12 17:55:47 Krak-des-Chevaliers /Applications/Internet/Camino.app/Contents/MacOS/Camino: objc: Using implementation from /Applications/Internet/Camino.app/Contents/PreferencePanes/Navigation.prefPane/Contents/MacOS/Navigation.

Comment 1

[Stuart Morgan]

Right, we need the linker settings that say it's okay to have undefined symbols because we are 100% sure the bundle will be loaded into an app that defines them.

Comment 2

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

Stuart, is this something bug 383934 will fix?

Comment 3

[Stuart Morgan]

It should, yes.

Comment 4

[Mark Mentovai]

Another problem here is that there are some localized strings in AppListMenuFactory, but the translations are only in the main bundle's strings file, not in the Navigation.prefPane's strings file.

Comment 5

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

(In reply to comment #4)
> Another problem here is that there are some localized strings in
> AppListMenuFactory, but the translations are only in the main bundle's strings
> file, not in the Navigation.prefPane's strings file.

We need a separate bug on this, correct?  It's not something any of the pref-reorg stuff will ever eliminate the need for, because prefs will always be separate executables, right?

Comment 6

[Mark Mentovai]

Attachment: Patch

No separate bug needed.  This is really simple: the one true version of AppListMenuFactory will be in the application, and the preference pane will use that copy instead of its own copy.  That means that the only localization needed for anything in AppListMenuFactory is in the main bundle's strings file.  The only localization currently present in the preference pane's strings file for AppListMenuFactory is "Select...".  We can just take that out here, since nothing else in the preference pane needs it.  We don't need to add it to the application's strings file because it's already there.

The attribute(visibility(default)) and attribute(used) stuff is to keep the symbols public and not dead-stripped, respectively.  Since the preference pane will be accessing those symbols, we need to make sure they're available.

Comment 7

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

Comment on attachment 292554 [details] [diff] [review]
Patch

r=ardissone

I don't see any ill effects, and "Select…" still appears in General's pop-ups, but I can't trigger the warning even before your patch (and I don't see it in any recent console.logs, either), and this is not really my area of expertise, so please have someone else look at (r or sr) the code, too.

Comment 8

[Stuart Morgan]

Comment on attachment 292554 [details] [diff] [review]
Patch

sr=smorgan

Comment 9

[Mark Mentovai]

Checked in on the trunk and MOZILLA_1_8_BRANCH for 1.6b1.

Comment 10

[Mark Mentovai]

Backed out from MOZILLA_1_8_BRANCH temporarily.  While linking Navigation.prefPane with gcc 3.3, smorgan got:

ld: Undefined symbols:
.objc_class_name_AppListMenuFactory
/Volumes/CaminoBranch18Static/objdir/ppc/camino/build/Camino.build/Deployment/NavigationPrefPane.build/Objects-normal/ppc/Navigation.o reference to undefined .objc_class_name_AppListMenuFactory

Comment 11

[Stuart Morgan]

I actually got the failure when I tried to build just i386 later too (so gcc4)

Comment 12

[Mark Mentovai]

Yeah, the Tiger tinderboxen caught fire too, even on the trunk, which uses gcc 4 for both architectures.  It's probably a Tiger ld thing.  I've backed out from the trunk and branch and will figure out how to keep Tiger ld from dead-stripping or hiding that symbol.

Comment 13

[Mark Mentovai]

It's a problem with ld in Xcode 2.x.  2.4.1 and 2.5 seem to be affected.  3.0 is OK.  As a workaround, we can tell the linker that the symbol is used and not a candidate for dead-stripping.  Unfortunately, there's no good syntax to do that with an Objective-C class, so we've got to do:

asm(".no_dead_strip .objc_class_name_AppListMenuFactory");

Checked in again with that, plus a comment.

Comment 14

[Mark Mentovai]

Yup, that works.

Let me know the next time we need to access something in the main executable from a prefpane now that bundle_loader is working, especially if you find that it doesn't work or doesn't work in some configurations.  smorgan, you may fall into this category.  If we hit another one of these, we'll probably want to make macros to get the exporting and no-dead-stripping right.