295517 - Build fails in uriloader/extandler under BeOS

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Edward Dore]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: 

Build fails on BeOS in uriloader/extandler
The BeOS specific mailto code seems to be responsible

Reproducible: Always

Steps to Reproduce:
1. clean CVS checkout
2. normal build with standard BeOS .mozconfig
Actual Results:  
c++ -o nsOSHelperAppService.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"BeOS5.0\"
-DOSARCH=\"BeOS\" -DBUILD_ID=0000000000 -I. -I../../dist/include/xpcom
-I../../dist/include/string -I../../dist/include/unicharutil
-I../../dist/include/mimetype -I../../dist/include/uriloader
-I../../dist/include/necko -I../../dist/include/rdf
-I../../dist/include/webshell -I../../dist/include/plugin
-I../../dist/include/pref -I../../dist/include/intl -I../../dist/include/uconv
-I../../dist/include/docshell -I../../dist/include/windowwatcher
-I../../dist/include/embed_base -I../../dist/include/toolkitcomps
-I../../dist/include/exthandler -I../../dist/include -I../../dist/include/nspr
-I../../dist/sdk/include -fPIC -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 -pipe -DNDEBUG -DTRIMMED -O
-DMOZILLA_CLIENT -include ../../mozilla-config.h
-Wp,-MD,.deps/nsOSHelperAppService.pp ./beos/nsOSHelperAppService.cpp
/boot/home/mozilla/uriloader/exthandler/beos/nsOSHelperAppService.cpp: In method
`nsresult nsOSHelperAppService::LoadUriInternal(class nsIURI *)':
/boot/home/mozilla/uriloader/exthandler/beos/nsOSHelperAppService.cpp:119:
non-lvalue in unary `&'
/boot/home/mozilla/uriloader/exthandler/beos/nsOSHelperAppService.cpp:123:
non-lvalue in unary `&'
make[4]: *** [nsOSHelperAppService.o] Error 1
make[4]: Leaving directory `/boot/home/mozilla/uriloader/exthandler'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/boot/home/mozilla/uriloader'
make[2]: *** [tier_9] Error 2
make[2]: Leaving directory `/boot/home/mozilla'
make[1]: *** [alldep] Error 2
make[1]: Leaving directory `/boot/home/mozilla'
make: *** [alldep] Error 2

Expected Results:  
compiled cleanly

Comment 1

[Edward Dore]

Attachment: uriloader/exthandler fix

This fixes the BeOS specifis mailto code in uriloader/exthandler

Comment 2

[Prognathous]

Thanks for the patch, Edward. I'm assigning this bug to you. You might want to
ask someone (S_D?) to review your patch.

Prog.

Comment 3

[tqh]

Updated title so we can keep track of it. Is this while building Firefox or
Mozilla, if it's for Firefox I'm curious why I've never seen it.

Comment 4

[Edward Dore]

This is from a Firefox build, I haven't tried it with SeaMonkey yet but I will
tonight
I don't know why other BeZilla devs haven't seen it before but this is a clean
install of R5.03 Pro with make 3.79.1, perl 5.8 and CVS 1.11 installed and the
BeOS glib/libIDL on the mozilla ftp server
It's a clean checkout from the CVS server and it happens every time, I have
reinstalled this setup on numerous machines now and this always happens

Comment 5

[tqh]

Are you using the new 'more bugfixed' gcc from Oliver Tappe. It's better than
all the others, with more correct code and better handling of optimizations.

http://www.bebits.com/app/4011

Comment 6

[Simon]

Try running gcc -v, I get this:
gcc version 2.95.3-beos-041202

Anyway I don't understand why it trips up on that code for you, when it builds
for everyone else, but the code in the patch is more correct (argv should be a
char* array), so it should be checked in anyway.

Btw, just check a mailto: link still works correctly in one of your builds.

Comment 7

[Edward Dore]

no new GCC (yet)
gcc -v gives gcc-2.9-beos-991026
BeMail (defaul app) launches and the TO: field is filled in
The SUBJECT: field is not but launching it from the terminal doesn't work
either, it expects a seperate argument

Comment 8

[tqh]

Ok, as it should be changed anyway I'm confirming it.

Comment 9

[tqh]

Comment on attachment 184536 [details] [diff] [review]
uriloader/exthandler fix

r=[e-mail]

Comment 10

[Simon]

Yeh subject works with Beam but not with BeMail, I consider it a BeMail
issue...if it accepts the to: as a mailto: it should really parse the whole
thing for the other tags.

The new GCC is by far and away the best compiler we have on BeOS - just make
sure you follow the instructions in full (even the ones marked as optional) when
installing it. Read the readme thoroughly, there's a bit in there I think about
changing the default libs so that mozilla/firefox still build. That's obviously
why you're the only one seeing the issue.

It still is an issue though and the patch still improves the code so should be
applied.

Comment 11

[Prognathous]

I'm adding a link to the previous /beos/nsOSHelperAppService.cpp bug.

Asaf, can you check this patch in? It's BeOS-only, so no sr is needed.

Thanks!

Prog.

Comment 12

[Asaf Romano (gone)]

Comment on attachment 184536 [details] [diff] [review]
uriloader/exthandler fix

It needs approval.

Comment 13

[Prognathous]

Yeap, that's right. I didn't notice the freeze.

Prog.

Comment 14

[Asaf Romano (gone)]

Checking in nsOSHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/beos/nsOSHelperAppService.cpp,v  <-- 
nsOSHelperAppService.cpp
new revision: 1.13; previous revision: 1.12
done