From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.4.0-test2 alpha; Nav) BuildID: 2000182349127863 The file: xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_osf1_alpha.s requires cpp preprocessing before assembly. To enable this, it should be named with a .S (note capital S). Reproducible: Always Steps to Reproduce: 1.compile with CC=ccc CXX=cxx using Compaq's compilers on linux/alpha. 2. 3. Actual Results: Expected Results: To allow the lizard to be compiled with Compaq's ccc/cxx compilers under linux/alpha, change: In xpcom/reflect/xptcall/src/md/unix/Makefile.in: # # Linux/Alpha # ifneq (,$(filter Linuxalpha FreeBSDalpha NetBSDalpha,$(OS_ARCH)$(OS_TEST))) ifeq ($(GNU_CC),1) CPPSRCS := xptcinvoke_linux_alpha.cpp xptcstubs_linux_alpha.cpp else CPPSRCS := xptcinvoke_osf1_alpha.cpp xptcstubs_osf1_alpha.cpp ASFILES := xptcinvoke_asm_osf1_alpha.s xptcstubs_asm_osf1_alpha.S endif endif My apologies for not producing a proper patch. Renaming of the above .s file to .S causes some makefile code later on to barf because it doesn't know what .S is. (linking of libxpcom.so fails because the makefile passes the .S file to ld...which treats it as a script :() It appears that a make in xpcom/build will copy the .S file to xpcom/build and try to link it. Don't know why... This form sucks (http://www.mozilla.org/quality/help/bug-form.html)...there's no build ID (compiled by hand).
My problem with doing this kind of work is verifying that the patch works, since I lack the hardware. There are other patches for various platforms just waiting because I do not have the ability to test that it works on that platform. How should we procede on this?
leger? What's the Netscape-internal process for getting patches checked out on other platforms? Gerv
colin is the DEC guy, iirc?
Compaq (Digital) has a few operating systems. I am the OpenVMS guy. This problem is reported against a file that is specific to Digital UNIX, formerly OSF/1, now known as Tru64 UNIX. Although it looks like someone's trying to build on Linux on Alpha. Anyway, its not OpenVMS, so I'm afraid I'm not your guy.
Edward: Welcome to xpcom!
Once again... attempting to reassign from Ray to Edward.
Created attachment 19130 [details] [diff] [review] adds necessary asm for Linux/Alpha using Compaq's ccc compiler.
I just sent a patch to allow ccc to compile properly. The ASM is copied from the osf1 sources, and symbols changed for different symbol mangling. This compiler now has template instatiation problems (in xpcom) that I haven't resolved yet. Any suggestions would be appreciated, since gcc generates a REALLY slow mozilla on this platform. If there is confusion, this is for Linux on the alpha using Compaq's ccc compiler: http://www.support.compaq.com/alpha-tools/software/index.html Also if you guys want to test out the patch, Compaq has a "testdrive" program that will give you a shell account on a linux/alpha machine (or many other OS's), which could be useful for this purpose: http://www.testdrive.compaq.com/
I have no idea what to do with bug. I have no way of checking it out. Can someone take this one please (or let me know who to reassign it to). Thanks.
reassign all kandrot xpcom bug.
I'm not sure what I can do about this. I don't have an Alpha system to test this against.
I'm futuring this for now. I have no way of verifying this patch. Either someone else own it or get me access to an Alpha box ;-)
this bug looks the same as bug 124074...
*** Bug 124074 has been marked as a duplicate of this bug. ***
David Bradley wrote: > I'm futuring this for now. I have no way of verifying this patch. Either > someone else own it or get me access to an Alpha box ;-) What about using the SourceForge's CompileFarm machines ? They have a DEC Alpha box there...
Created attachment 104101 [details] rpm output Full build log and configure output per firstname.lastname@example.org's request. Also: [root@k2 bin]# ./run-mozilla.sh ./TestXPTCInvoke run-mozilla.sh: Cannot execute ./TestXPTCInvoke. I don't think the build process got far enough to be able to do the above.
Created attachment 104102 [details] mozilla-1.1.rpm.out.bz2 Full build log and configure output per email@example.com's request. Also: [root@k2 bin]# ./run-mozilla.sh ./TestXPTCInvoke run-mozilla.sh: Cannot execute ./TestXPTCInvoke. I don't think the build process got far enough to be able to do the above.
Jiann-Ming, can you modify your spec file so that it does not use 'make -s' and attach a new build log? I'd like to see the actual commands that are being used to create libxpcom.so.
Created attachment 104714 [details] Output of "rpm -ba --clean" make without the -s option
Created attachment 104733 [details] [diff] [review] Use CC & CXX to build shared libs I think the problem is that we're using ld to create libxpcom.so. This has proven problematic on linux in the past. This patch should force the use of $(CC) -shared & $(CXX) -shared to build the shared libs. It also kills the warning caused by using -mieee.
Created attachment 104827 [details] mozilla-1.1.rpm.out.bz2 New patches causes a different error now. I don't think it got quite as far in the compile process this time.
cxx -I/usr/X11R6/include -O2 -pthread -DNDEBUG -DTRIMMED -O -KPIC -shared -Wl,-soname -Wl,libmozjs.so -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o prmjtime.o -lm -ldl -L/usr/src/redhat/BUILD/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lc -ldl -lm -lc cxx: Info: Switch -pthread not supported on this platform...ignoring. ld: unrecognized option '--demangle=compaq' ld: use the --help option for usage information ld: unrecognized option '--demangle=compaq' ld: use the --help option for usage information make: *** [libmozjs.so] Error 1 It looks like that version of ld doesn't support the compaq compiler. Does building any non-mozilla c++ libraries or programs work? (Why we're linking JS using the c++ compiler is a separate issue.)
Created attachment 104928 [details] mozilla-1.1.rpm.out.bz2 Okay, I upgraded binutils and am now running ld version 126.96.36.199.2 20020802. Looks like ld is bombing on "-KPIC" for files compiled with cxx, while the ccc compiled files linked without problems.
In the previous patch, change DSO_CFLAGS=-fPIC to DSO_PIC_CFLAGS=-fPIC.
Created attachment 104932 [details] mozilla-1.1.rpm.out.bz2 Okay, I modified the patch. Here's the new output.
Created attachment 104936 [details] [diff] [review] add -fPIC to ASFLAGS cxx -I/usr/X11R6/include -O2 -pthread -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-soname -Wl,libxpcom.so -o libxpcom.so .... ld: xptcstubs_asm_linux_alpha_ccc.o: pc-relative relocation against dynamic symbol PrepareAndDispatch I think that problem is caused by not building the asm file with -fPIC. This patch should fix that.
Applied new patch, but same error, with a few minor differences: # diff rpm.out-latest rpm.out-previous 9639,9640c9639,9640 < ccc -o xptcinvoke_asm_linux_alpha_ccc.o -fPIC -I../../../../../../dist/include /xpcom -c xptcinvoke_asm_linux_alpha_ccc.s < ccc -o xptcstubs_asm_linux_alpha_ccc.o -fPIC -I../../../../../../dist/include/ xpcom -c xptcstubs_asm_linux_alpha_ccc.S --- > ccc -o xptcinvoke_asm_linux_alpha_ccc.o -I../../../../../../dist/include/xpco m -c xptcinvoke_asm_linux_alpha_ccc.s > ccc -o xptcstubs_asm_linux_alpha_ccc.o -I../../../../../../dist/include/xpcom -c xptcstubs_asm_linux_alpha_ccc.S
So according to the messages at http://sources.redhat.com/ml/libc-hacker/2002-06/msg00022.html & http://www.somelist.com/mails/104792.html , recent versions of binutils trigger that error when a relocation cannot be computed at link time. The fix for symbols that exist in the same asm file is straight forward but I don't see any examples for external symbols. You may have to experiment.
*** Bug 175546 has been marked as a duplicate of this bug. ***
Created attachment 115213 [details] new rpm output Okay, finally upgraded to Compaq's latest compilers. Tried building mozilla 1.2.1 and now getting a bit farther it seems. The src rpm compiles fine with gcc.