361542 - [BeOS] Linking fails in toolkit/components

Status: RESOLVED FIXED

(Toolkit Graveyard :: Security, defect)

Description

[Doug Shelton]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1

Sometime between 2006-11-11 and 2006-11-22, linking broke in toolkit/components.  Text of failure is
c++  -frtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-multichar -Wno-long-long -pedantic -pipe  -DNDEBUG -DTRIMMED -O2 -nostart -Wl,-h,libtoolkitcomps.so -o libtoolkitcomps.so  nsToolkitCompsModule.o       -Wl,--whole-archive ../startup/src/libappstartup_s.a  ../downloads/src/libdownload_s.a ../../../dist/lib/liburlclassifier_s.a ../../../dist/lib/libfeed_s.a ../typeaheadfind/src/libfastfind_s.a -Wl,--no-whole-archive -L../../../dist/bin -L../../../dist/lib -lgkgfx ../../../dist/lib/libunicharutil_s.a -L../../../dist/bin -lxpcom -lxpcom_core -L../../../dist/bin -L../../../dist/lib -lplds4 -lplc4 -lnspr4 -lbind -lsocket -L../../../dist/bin -lmozjs   -lsocket  -lbe -lbind -lzeta   
../../../dist/lib/liburlclassifier_s.a(nsUrlClassifierDBService.o)(.nsUrlClassifierDBService::gnu.linkonce.t.GetIID(void)+0x12): Infunction `nsUrlClassifierDBService::GetIID(void)':
: undefined reference to `nsUrlClassifierDBService::COMTypeInfo<int>::kIID'
collect2: ld returned 1 exit status
 

Reproducible: Always

Comment 1

[Doug Shelton]

Not sure if this is the right classification but seems to be related to this function.

Comment 2

[Doug Shelton]

Looks like this might be a regression caused by bug 356355.

Comment 3

[Tony Chang (Google)]

Can't be bug 356355, that change only has to do with javascript.  Might be caused by bug 343033, but that seems unlikely because nsUrlClassifierDBService hasn't changed much in a long time.

Comment 4

[Doug Shelton]

(In reply to comment #3)
> Can't be bug 356355, that change only has to do with javascript.  Might be
> caused by bug 343033, but that seems unlikely because nsUrlClassifierDBService
> hasn't changed much in a long time.
> 
Agreed - sorry for the false alarm.

Comment 5

[Doug Shelton]

This is a regression from bug 310309 and may not be fixable because of BeOS's use of very old (2.95.3) gcc.  Leaving this bug open as a possible place to put BeOS workarounds for this regression.

Comment 6

[Tony Chang (Google)]

What's the appropriate component?

Comment 7

[Doug Shelton]

changing to "core/xpcom" since that's where the cause of this issue lies.

Comment 8

[Doug Shelton]

(In reply to comment #6)
> What's the appropriate component?
> 
To my untrained eye, it looks like the cause is here http://lxr.mozilla.org/seamonkey/source/xpcom/glue/nsISupportsImpl.h#430.  I'm hoping we can find a way to simply use older versions of this code in BeOS builds without having to completely branch away from all trunk development.  

Comment 9

[tqh]

Are there any other ports stuck with gcc2.X? In that case it's not just a BeOS-bug.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

probably not... I don't think any other OSes use C++ for their system API.

Comment 11

[tqh]

I've come to suspect that all that is needed to fix this is a 

NS_DEFINE_STATIC_IID_ACCESSOR(nsUrlClassifierDBService, NS_URLCLASSIFIERDBSERVICE_CID)

in nsUrlClassifierDBService.h

Maybe newer gcc's are to smart when people miss to define static variables correctly?

Hopefully the build I'm doing now will succeed.

Comment 12

[tqh]

Attachment: Suggested fix

this patch fixes the build by defining space for the static var. Dunno why newer gcc's get past it.

Comment 13

[tqh]

Changing back to toolkit component, as no need to change anything in xpcom (and it ain't broken).

Comment 14

[tqh]

Comment on attachment 249748 [details] [diff] [review]
Suggested fix

r?

Defining IID for nsUrlClassifierDBService seems to be the only stopping point for gcc2.95.3 as talked about in bug 313309. As I understand it, it is a bug in the code and not a problem with gcc2.95, although newer compilers seem to forgive this.

Need help commiting on review..

Comment 15

[Doug Shelton]

Confirming, tqh's fix allows the trunk to build here and fixes the bug as reported.

Comment 16

[Doug Shelton]

Comment on attachment 249748 [details] [diff] [review]
Suggested fix

Requesting 2nd review - not sure if it's necessary but trying to be safe.

Comment 17

[Doug Shelton]

Comment on attachment 249748 [details] [diff] [review]
Suggested fix

second review requested.  not sure if necessary but want to be safe since this is outside BeOS-only code.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 249748 [details] [diff] [review]
Suggested fix

Second review isn't needed, go ahead and land this.

Comment 19

[Sergei Dolgov]

Checking in mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.h;
/cvsroot/mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.h,v  <--  nsUrlClassifierDBService.h
new revision: 1.3; previous revision: 1.2
done