Nekochan Net • View topic - Firefox 10 Porting Progress

View unanswered posts | View active topics View unread posts

Board index » SGI » SGI: Development

All times are UTC - 8 hours

Forum rules

Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.

Firefox 10 Porting Progress

Page 2 of 7

[ 94 posts ]

Go to page Previous 1, 2, 3, 4, 5 ... 7 Next

Print view

Previous topic | First unread post | Next topic

Author

Message

jan-jaap

Post subject: Re: Firefox 10 Porting Progress

Posted: Tue Mar 20, 2012 1:30 am

Joined: Thu Jun 17, 2004 10:35 am
Posts: 3577
Location: Wijchen, The Netherlands

kubatyszko wrote:

Would moving you to dual 600Mhz, 4.5G RAM Octane2 help ?

Only for the extra CPU muscle.

NCommander wrote:

I could go hunting through binutils and see if it uses MAP_FIXED + MAP_AUTOGROW, and change it, but I also doubt that will help ...

You're using GNU ld? It is recommended to configure GCC to use GNU as (it's required for certain features), but use IRIX ld.

An N32 process (such as the linker) can at the best allocate ~ 1.7GB. If shared libraries are mapped unfavorably, this number can be much lower.

Dave Anderson (who worked (works?) in the compiler group) posted a couple of messages in this thread to make the best of the N32 address space.

If that doesn't do the trick, MIPSpro 7.4.1 introduced a prototype 64-bit linker:

Code:

          3.2.1  New 64-bit built linker   Under certain
          circumstances the default linker (because it is
          built in the N32 ABI) could   run out   of virtual
          address space and exit with   an error: "I/O
          Error: Out of Space". To address only those
          types of error, MIPSpro 7.4.1m provides an
          experimental linker   built as a 64-bit binary,
          ld64x, which can be   invoked   as:

          %cc   -64 -Zl,x t.c

          This linker   cannot be used in conjunction with
          -IPA and is   only provided as a workaround when
          encountering the above error.

Bug fixes were made all the way to the very last (7.4.4) release; I don't know how stable it really is. I'm not sure how to mod GCC to use it. There's no such thing as ldx32 so this 64-bit ld binary can only be used to produce 64-bit binaries.

If you really want to enter a new world of pain, you could rebuild GNU binutils as N64 binaries to create a 64-bit toolchain capable of building 32-bit binaries. I'm pretty sure you'd be the first. No wait, if I have time later today I'll give it a shot. See what this does for the regression results :twisted:

The workaround (stripping debug info before linking) is probably a better option

_________________
Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

Top

NCommander

Post subject: Re: Firefox 10 Porting Progress

Posted: Tue Mar 20, 2012 5:36 am

Joined: Thu Feb 23, 2012 8:53 am
Posts: 37

kubatyszko wrote:

Would moving you to dual 600Mhz, 4.5G RAM Octane2 help ?

That can be arranged pretty quickly, I'd only need a fresh install of 6.5.22.

Not really sure. Short of smackng binutils and rebuilding GCC, I'm at a loss. In addition, this might be a hard limitation sinceI belive GNU ld uses mmap() as well, leaving cross-compilation the only option.

I'm a bit bogged down this week so I probably won't get to dig into more until Thursday or Friday ...

Top

kubatyszko

Post subject: Re: Firefox 10 Porting Progress

Posted: Tue Mar 20, 2012 5:44 am

Joined: Sat Nov 12, 2011 3:18 am
Posts: 296
Location: Tokyo

Give the IRIX ld combination a try just like Jan-Jaap mentioned, this seems to be the last hope...

_________________
[click for links to hinv] JP: [ :O200:

:Fuel: :Octane2: :Octane:

:O2: :Indy: :Indy:

] PL: [ :Fuel: :O2:

]
For Sale: 2*O200 M/B, 2*O200 PSU, 6*256MB O200 RAM, 2*O200 SCSI Backplane, 2*O200 MSC, DMediaPro DM-2 ( 030-1653-002 Rev. H , XT-DIGVID) with Octane XIO pull (Origin pull optionally available)

Top

NCommander

Post subject: Re: Firefox 10 Porting Progress

Posted: Tue Mar 20, 2012 5:38 pm

Joined: Thu Feb 23, 2012 8:53 am
Posts: 37

kubatyszko wrote:

Give the IRIX ld combination a try just like Jan-Jaap mentioned, this seems to be the last hope...

I thought I posted that I did and it didn't make a difference; it still mmap's the output file ...

EDIT: Hrm, I didn't see that 64 bit linker option but I'm not building with MIPSpro (the chromium code is full of GCC-isms, I suspect getting it to compile with it would be borderline impossible). I'll have to dig out what command is being used, and manually link in the final step or see if GCC lets me specify a different LD (it can be done via specfile editing, but thats ... messy)

Top

oreissig

Post subject: Re: Firefox 10 Porting Progress

Posted: Thu Mar 22, 2012 1:17 pm

Joined: Thu Jun 02, 2011 2:13 pm
Posts: 86
Location: Germany

Just read the release notes for the new GCC 4.7 and there's the following detail in it:

Quote:

Improved scalability and reduced memory usage. Link time optimization of Firefox now requires 3GB of RAM on a 64-bit system, while over 8GB was needed previously. Linking time has been improved, too. The serial stage of linking Firefox has been sped up by about a factor of 10.

Does this have any relevance for this thread?

I was just wondering, aren't link time optimizations performed by the linker? Then why is this listed in the gcc changelog, I thought the linker was part of binutils?

oh and IRIX 6.5 has been obsoleted in this release, so its support will be dropped in the next release

Top

kubatyszko

Post subject: Re: Firefox 10 Porting Progress

Posted: Thu Mar 22, 2012 2:32 pm

Joined: Sat Nov 12, 2011 3:18 am
Posts: 296
Location: Tokyo

8GB you're saying, it's more than 1.5G RAM + 4G SWAP I have on that box, maybe it is relevant...

_________________
[click for links to hinv] JP: [ :O200:

:Fuel: :Octane2: :Octane:

:O2: :Indy: :Indy:

] PL: [ :Fuel: :O2:

]
For Sale: 2*O200 M/B, 2*O200 PSU, 6*256MB O200 RAM, 2*O200 SCSI Backplane, 2*O200 MSC, DMediaPro DM-2 ( 030-1653-002 Rev. H , XT-DIGVID) with Octane XIO pull (Origin pull optionally available)

Top

jpstewart

Post subject: Re: Firefox 10 Porting Progress

Posted: Thu Mar 22, 2012 3:34 pm

Joined: Tue Sep 21, 2010 2:31 pm
Posts: 160
Location: Southwestern Ontario, Canada

oreissig wrote:

Does this have any relevance for this thread?

Probably not. It requires passing a special flag (-flto) to GCC at compile time to enable Link Time Optimizations. I doubt that's the case for the Firefox build system.

oreissig wrote:

I was just wondering, aren't link time optimizations performed by the linker? Then why is this listed in the gcc changelog, I thought the linker was part of binutils?

"Link Time Optimization" probably doesn't mean what you think it does. Read up on it in the GCC wiki here: http://gcc.gnu.org/wiki/LinkTimeOptimization. In short, it is indeed a GCC feature and nothing to do with the linker.

_________________

Sun SPARCstation 20, Blade 2500
HP C8000

Top

oreissig

Post subject: Re: Firefox 10 Porting Progress

Posted: Thu Mar 22, 2012 4:03 pm

Joined: Thu Jun 02, 2011 2:13 pm
Posts: 86
Location: Germany

jpstewart wrote:

It requires passing a special flag (-flto) to GCC at compile time to enable Link Time Optimizations. I doubt that's the case for the Firefox build system.

but they explicitly name firefox as example, where this new optimization is effective

Top

NCommander

Post subject: Re: Firefox 10 Porting Progress

Posted: Thu Mar 22, 2012 4:42 pm

Joined: Thu Feb 23, 2012 8:53 am
Posts: 37

I don't seem to have ld64x on this system, but with a fair bit of pain, I managed this last night:

Code:

michael@IRIS:~/porting/mozilla-irix/widget/src/qt$ file ~/local/gcc/bin/gld 
/usr/people/michael/local/gcc/bin/gld:  ELF 64-bit MSB mips-3 dynamic executable (not stripped) MIPS - version 1

Rebuilding GCC now with binutils ld.I tried this earlier but ran into issues with the linker, so I'llhave to debug binutils.

I think it is safe to say at this point that even if I manage to get firefox working, we'll never build it with MIPSpro (unless theres an insane way to use GNU ld with MIPSpro ...)

Top

NCommander

Post subject: Re: Firefox 10 Porting Progress

Posted: Fri Mar 23, 2012 6:09 am

Joined: Thu Feb 23, 2012 8:53 am
Posts: 37

NCommander wrote:

I don't seem to have ld64x on this system, but with a fair bit of pain, I managed this last night:

Code:

michael@IRIS:~/porting/mozilla-irix/widget/src/qt$ file ~/local/gcc/bin/gld 
/usr/people/michael/local/gcc/bin/gld:  ELF 64-bit MSB mips-3 dynamic executable (not stripped) MIPS - version 1

So ... while I found binutils 2.22 is in utter fucked mode on IRIX, 2.19 works decently, and passes most of its test suite (there are some bugs, but I'm not sure its a showstopped). I've also seen 2.19 has been used to build IRIX cross-compilers in the past, so I'm rebuilding with it, and have a 64-bit native gld. GCC is rebuilding now.

If this fails, the firefox 10 port is pretty much dead :-/.

If I get a linking firefox with 2.19. I'll try and see if I can fix the regression and stop the linker from sobbing in the corner.

Top

bplaa.yai

Post subject: Re: Firefox 10 Porting Progress

Posted: Fri Mar 23, 2012 6:54 am

Joined: Wed Mar 26, 2008 11:04 am
Posts: 302
Location: Paris

jan-jaap wrote:

From man(1) ld:

Code:

I/O Options
     The options affect I/O:

     -mmap     Directs the linker to use mmap(2) as its preferred mode for
               reading object files.  This usually results in better I/O
               performances, except when using NFS mounted files with high
               network latencies.  This is enabled by default.

     -read     Directs the linker to use the open(2), lseek(2), and read(2)
               utilities as its preferred mode for reading object files.
               Setting this option when many object files are remotely
               mounted with high network latency often improves
               performance.

Try to pass the linker option '-read' to work around mmap limitations?

Very nice find jan-jaap ! (sometimes I should read the docs more carefully... :oops:

)

I tested adding -Wl,-read in my LDFLAGS (well, QMAKE_LFLAGS in qmake.conf in that case), clean & rebuilt libQtWebkit, and everything went smoothly

Code:

CC -n32 -L/usr/nekoware/lib -L/usr/nekoware/pgsql/lib -L/usr/nekoware/mysql4/lib/mysql -Wl,-read -Wl,-rpath -Wl,/usr/nekoware/qt4/lib:/usr/nekoware/lib:/usr/nekoware/pgsql/lib:/usr/nekoware/mysql4/lib/mysql -Wl,-rpath,/usr/nekoware/qt4/lib -Wl,-rpath,/usr/nekoware/qt4/lib -shared -Wl,-soname,libQtWebKit.so.4 -o libQtWebKit.so.4.7.3 <snip lots of objects files> -L/usr/people/julien/build/qt-everywhere-opensource-src-4.7.3-sgi/lib -L../JavaScriptCore/release -ljscore -L/usr/people/julien/build/qt-everywhere-opensource-src-4.7.3-sgi/lib -lXrender -lphonon -lQtGui -lQtNetwork -lQtCore -lpthread -lXrender -L/usr/nekoware/lib -lfontconfig -lfreetype -lXext -lX11 -lm 
<snip lots of multiply defined warnings>
ld32: Giving up after printing 50 warnings.  Use -wall to print all warnings.
ld32: INFO    171: Multigot invoked. Gp relative region broken up into 15 separate regions.
ln -s libQtWebKit.so.4.7.3 libQtWebKit.so
ln -s libQtWebKit.so.4.7.3 libQtWebKit.so.4
ln -s libQtWebKit.so.4.7.3 libQtWebKit.so.4.7
rm -f ../../../../lib/libQtWebKit.so.4.7.3
rm -f ../../../../lib/libQtWebKit.so
rm -f ../../../../lib/libQtWebKit.so.4
rm -f ../../../../lib/libQtWebKit.so.4.7
mv -f libQtWebKit.so.4.7.3 libQtWebKit.so libQtWebKit.so.4 libQtWebKit.so.4.7 ../../../../lib/

Resulting libQtWebKit.so.4.7.3 is 635M (instead of 314M in the stripped version).

_________________
:Onyx2:

Top

NCommander

Post subject: Re: Firefox 10 Porting Progress

Posted: Fri Mar 23, 2012 8:33 am

Joined: Thu Feb 23, 2012 8:53 am
Posts: 37

bplaa.yai wrote:

jan-jaap wrote:

From man(1) ld:

Code:

I/O Options
     The options affect I/O:

     -mmap     Directs the linker to use mmap(2) as its preferred mode for
               reading object files.  This usually results in better I/O
               performances, except when using NFS mounted files with high
               network latencies.  This is enabled by default.

     -read     Directs the linker to use the open(2), lseek(2), and read(2)
               utilities as its preferred mode for reading object files.
               Setting this option when many object files are remotely
               mounted with high network latency often improves
               performance.

Try to pass the linker option '-read' to work around mmap limitations?

Very nice find jan-jaap ! (sometimes I should read the docs more carefully... :oops:

)

I tested adding -Wl,-read in my LDFLAGS (well, QMAKE_LFLAGS in qmake.conf in that case), clean & rebuilt libQtWebkit, and everything went smoothly

Code:

CC -n32 -L/usr/nekoware/lib -L/usr/nekoware/pgsql/lib -L/usr/nekoware/mysql4/lib/mysql -Wl,-read -Wl,-rpath -Wl,/usr/nekoware/qt4/lib:/usr/nekoware/lib:/usr/nekoware/pgsql/lib:/usr/nekoware/mysql4/lib/mysql -Wl,-rpath,/usr/nekoware/qt4/lib -Wl,-rpath,/usr/nekoware/qt4/lib -shared -Wl,-soname,libQtWebKit.so.4 -o libQtWebKit.so.4.7.3 <snip lots of objects files> -L/usr/people/julien/build/qt-everywhere-opensource-src-4.7.3-sgi/lib -L../JavaScriptCore/release -ljscore -L/usr/people/julien/build/qt-everywhere-opensource-src-4.7.3-sgi/lib -lXrender -lphonon -lQtGui -lQtNetwork -lQtCore -lpthread -lXrender -L/usr/nekoware/lib -lfontconfig -lfreetype -lXext -lX11 -lm 
<snip lots of multiply defined warnings>
ld32: Giving up after printing 50 warnings.  Use -wall to print all warnings.
ld32: INFO    171: Multigot invoked. Gp relative region broken up into 15 separate regions.
ln -s libQtWebKit.so.4.7.3 libQtWebKit.so
ln -s libQtWebKit.so.4.7.3 libQtWebKit.so.4
ln -s libQtWebKit.so.4.7.3 libQtWebKit.so.4.7
rm -f ../../../../lib/libQtWebKit.so.4.7.3
rm -f ../../../../lib/libQtWebKit.so
rm -f ../../../../lib/libQtWebKit.so.4
rm -f ../../../../lib/libQtWebKit.so.4.7
mv -f libQtWebKit.so.4.7.3 libQtWebKit.so libQtWebKit.so.4 libQtWebKit.so.4.7 ../../../../lib/

Resulting libQtWebKit.so.4.7.3 is 635M (instead of 314M in the stripped version).

seems libQtWebKit.so is smaller thatn Gecko; ld for me dies out writing the file (which appears it exceeds the 1 GiB limit O_O). What was the specific ld error you got without -read? (mine is can't mmap output file)

Additional note: I also tried using sgi_use_anyaddr to get around the 1 GiB limit. ld ran for a LOT longer before it died again.

Son of edit: I have patches that might get V8 (or at least JSC) working on MIPS. It might be more feasible to go the webkit route because this toolchain is quickly dipping into insanity.

Top

jan-jaap

Post subject: Re: Firefox 10 Porting Progress

Posted: Fri Mar 23, 2012 9:14 am

Joined: Thu Jun 17, 2004 10:35 am
Posts: 3577
Location: Wijchen, The Netherlands

Two things:

1. Re. My remark about re-quickstarting all binaries to make the best of the N32 address space: this has to be done by the root user. I understand this is not your system.

2. Otherwise you can always strip the debug info from the object code to reduce object size in order to fit it all inside the mmap() limitations of ld.

Either of these (or the combination) might do the trick.

_________________
Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

Top

bplaa.yai

Post subject: Re: Firefox 10 Porting Progress

Posted: Fri Mar 23, 2012 9:32 am

Joined: Wed Mar 26, 2008 11:04 am
Posts: 302
Location: Paris

NCommander wrote:

Without the -read option I was having the very same error as you, despite the output file being less than 1GB.
Before the nice suggestion of jan-jaap about the -read option, my workaround was to strip all object files before linking. It's worth trying I think (and jan-jaap too

)

NCommander wrote:

Additional note: I also tried using sgi_use_anyaddr to get around the 1 GiB limit. ld ran for a LOT longer before it died again.

Son of edit: I have patches that might get V8 (or at least JSC) working on MIPS. It might be more feasible to go the webkit route because this toolchain is quickly dipping into insanity.

I'm very curious about these patches. Are they against JSC or V8 ? I've worked on both, and JSC seems to be a closer target...

_________________
:Onyx2:

Top

NCommander

Post subject: Re: Firefox 10 Porting Progress

Posted: Fri Mar 23, 2012 9:50 am

Joined: Thu Feb 23, 2012 8:53 am
Posts: 37

bplaa.yai wrote:

NCommander wrote:

)

NCommander wrote:

I'm very curious about these patches. Are they against JSC or V8 ? I've worked on both, and JSC seems to be a closer target...

I tried -Wl,-read and ld still blew itself to bits. I'm retrying it now, but I do have a plan b in motion.

Here's my libxul link command

Code:

/usr/nekoware/bin/python2.5 /usr/people/michael/porting/mozilla-irix/config/pythonpath.py -I../../config /usr/people/michael/porting/mozilla-irix/config/expandlibs_exec.py --uselist --  g++ -I/usr/people/michael/local/include -I/usr/include -I/usr/nekoware/include -fno-rtti -Wl,-read -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -pipe  -DDEBUG -D_DEBUG -DTRACING -g -fno-omit-frame-pointer -fPIC -shared -Wl,-h,libxul.so -o libxul.so  nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsRDFResource.o    -Wl,-read -lpthread -L/usr/people/michael/local/lib -L/usr/nekoware/lib   -Wl,-rpath,/usr/people/michael/porting/obj1-mips-sgi-irix6.5/dist/bin -Wl,-rpath,/usr/people/michael/local/lib   ../../toolkit/xre/libxulapp_s.a  ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libjetpack_s.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libfileview.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/components/libgkdebug.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a ../../staticlib/libgfx2d.a ../../staticlib/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libmozreg_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libthebes.a ../../staticlib/libycbcr.a ../../staticlib/libangle.a  -L../../dist/bin -L../../dist/lib ../../media/libjpeg/libmozjpeg.a ../../media/libpng/libmozpng.a ../../gfx/qcms/libmozqcms.a /usr/people/michael/porting/obj1-mips-sgi-irix6.5/dist/lib/libmozjs.a -L../../dist/bin -L../../dist/lib -lcrmf -lsmime3 -lssl3 -lnss3 -lnssutil3 -L/usr/people/michael/local/lib -lcairo -lpixman-1 -lfreetype -lfontconfig    -L/usr/people/michael/local/lib -L/usr/nekoware/lib -lSM -lICE -lXrender -lX11 -lcairo   ../../gfx/harfbuzz/src/libmozharfbuzz.a ../../gfx/ots/src/libmozots.a  ../../dist/lib/libmozsqlite3.a  -lz  -L../../dist/bin -L../../dist/lib  -L/usr/people/michael/porting/obj1-mips-sgi-irix6.5/dist/lib -lplds4 -lplc4 -lnspr4 -L/usr/people/michael/local/lib -ldl -lpthread ../../dist/lib/libmozalloc.a  -lX11  -lXext  -pthread -L/usr/people/michael/local/lib -lpangoft2-1.0 -lfreetype -lfontconfig -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl   -pthread -L/usr/people/michael/local/lib -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lgdk-x11-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lintl   -lXt -lgthread-2.0 -L/usr/people/michael/local/lib -lfreetype -lz -lbz2 -lsocket 

(incidently, IRIX's max args had to be bumped quite a few times to run this monster)

EDIT: I'm too sleep-deprieved to post. Porting JSC to IRIX is probably less pain than getting firefox going IF Qt works decently under IRIX. Any comments on the usability of webkit on IRIX on performance?

EDIT2: So ... rebuilding GCC with GNU ld segfaulted the linker about 20 hours in ...

I'm running out of ideas here ... (short of building firefox 64-bit nativeand try using that experimental linker, if its possible to use it with gcc)

Top

Page 2 of 7

[ 94 posts ]

Go to page Previous 1, 2, 3, 4, 5 ... 7 Next

Board index » SGI » SGI: Development

All times are UTC - 8 hours

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum