Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: rsaxvc on February 28, 2010, 08:49:07 pm
-
So one time, I bought this sweet Sun Workstation on craigslist, Opteron64 and Quadro and everything...
So far, autogen.sh needs to be edited to allow autotools version 1.10 to work, bug filed on mantis.
conftest.c comes out empty when testing for SDL, leading to a linker error for missing main.
Anyone familiar with our build system / autotools have an idea?
-
FSO probably doesn't really support Solaris - but I honestly can't remember what flavour of Unix it is!
-
I understand that it doesn't support Solaris, but I would like to fix that - that's why I created this thread.
Solaris is based on System 5 Rel 4.
-
who actually uses solaris for games?
-
It can run Doom, or Quake or something, I think. Maybe BZFlag :P
-
Ahem. Solaris was one of the first unix platforms for opengl, right after SGI, and I think around the same time as HP.
Specifically, my box has 4 pci-e x16 slots, so I could SLI whatever I wanted to, but one Quadro should be enough for fs2_open.
-
isn't solaris made for SPARC systems? would you need to compile for SPARC?
BTW you can get linux for SPARC.
-
Solaris is just a *NIX distribution, in the same way that Ubuntu is just a Linux distribution. While it still maintains compatibility for SPARC, it also runs on x86 and x64 architectures. I am assuming that rsaxvc is running Solaris on a more or less standard x86/x64 box.
-
Solaris was originally for Sparc but now there's Solaris x86 and even OpenSolaris x86. It's also not 'just UNIX'. Solaris is a completely different OS, as much as Linux or OS X are. Maybe even moreso than OS X.
He even did mention that it's running an Opteron64 so you even know exactly what type of CPU is in the box :doubt:
I have a feeling there's stuff going to be in the way with this but I'd love to be proven wrong.
-
He even did mention that it's running an Opteron64 so you even know exactly what type of CPU is in the box :doubt:
oh, yeah...
I focused on "sun workstation" and thought sparc.
-
Ahem. Sun boxes were originally Motorola 68k based. Then came Sun 386i. Then came Sparc, which they still produce. There has been a big movement toward x64 though.
I don't know if I'd agree with equating a 'Unix Distribution' with a 'Linux Distribution'. All linux distributions are a lot more similar to each other than man unix distros. At least linux distros all have a related kernel.
The box is surprisingly standard though. Normal bios even, none of that openprom terminal. Powersupply and sata connectors are weird though. Sata connector has 4 channels on it, and a hot-swap backplane attached to it.
Also, I got some code to compile today. Pretty sweet! However, I don't have root right now, nor do I have openAL, which I pretty much need root to install.
-
I post then read, its bad habit of mine.
-
is there a minimum version of gcc for fs2_open?
solaris comes with 3.4.3 by default :(
-
I'm sure it used to compile with 3.4.3, but something may have broken it since.
-
The problem I was having was caused by some inline mac assembly that leaked in.
I upgraded to gcc 4.? before I figured it out.
Also, it compiles!
Also, it links!
After getting Solaris to accept the homemade libraries, it crashes gdb :(
-
Don't run it through gdb?
-
It segfaults.
The biggest problems in compilation were assumptions about includes (if A includes B, I don't need to include B) that aren't true outside of linux and starfield code which has a bunch of variables named 'sun', which is defined to 1 on Solaris.
-
Haha system reserved names. That's awesome.
So I suppose the better way to do the includes is explicitly check if the header is defined, just to make sure it gets in one way or the other, or include it anyway and let the other header sort that out.
-
Or, for every define we use, just make sure to include the header, and the macroguards should figure everything else out.
FIONBIO (filio.h) was the only one I had trouble with.
-
Here's instructions to get solaris to compile/link.
http://rsaxvc.net/blog/doku.php?id=building_fs2_on_solaris (http://rsaxvc.net/blog/doku.php?id=building_fs2_on_solaris)
Remember kids, only you can prevent threadomancy.
-
Remember kids, only you can prevent threadomancy.
Divination through threads?
-
reviving an old forum topic
-
So, it turns out there's a bug in solaris that makes SDL not work when you have certain environment vars set. Good news is that it got to the point of not finding the game files.
-
Hey look.
Currently, the software believes it is running on a big endian machine. After hard coding a correction into pstypes.h, the game launches.
[attachment deleted by admin]
-
So you're on Solaris on an UltraSparc? Specs? I may have to dig out my pimped out Ultra 10 or Ultra 2 now, dammit. Or maybe find a way to get it onto that E250 in storage.
-
Still rolling with Ultra 40 M2. (2xOpteron2214, 16gb ram, nvidia gts 250, 8x500 sataII)
I have an Ultra 5, but compiling scp on it takes hours, and X is super slow. I also have a SPARCClassic, but nobody supports Sparc32 anymore.
Once Solaris x86 works, I might move on to Solaris/Sparc64, since I know someone I think I can borrow a sun blade 150 for a few weeks or so. Or... I might start on getting it running on HP/UX. I got my J5000 running (1 gig of ram, 2x440mhz PARISC2)
I need to pull down a known good copy of FS2, as sometimes I have issues with FotG at tip revision.
Also, the INTEL_INT macros and stwbrx() somehow do the wrong thing on every platform except linux/littleEndian, OSX, and windows/x86. On Solaris/x86, solaris/x64, linux/sparc, solaris/sparc, and hpux/parisc they don't work right. I also worry about alignment faults on those archs. Hopefully supporting PowerPC will have cleared them out, but when they happen, they choke performance: [[http://x264dev.multimedia.cx/?p=51]]
-
If you're still using the standalone subset of FS2 I released for FotG, you need asteroids. I'm going to update it shortly anyway, and I try to keep the FotG as it is in SVN compatible with some common set of builds (currently should still work on 3.6.12 if you leave the .tbm.bck files named that way).
If they work on OSX/x86-64 and OSX/PPC without changes, then there's a possibility there's still a problem. Plus we have sketchy PPC support at best these days anyway. I wish we had a few devs with more combinations of G4/G5 and 10.4/10.5 around.
So ok, the endian issue you ran into wasn't because you were running on strange hardware though, but because of software issues on Solaris/x86? Was just confused about that. Still, might be interesting to try to get it running on a FFB2+ if it has the OpenGL support for it.
-
OpenSolaris may be a dead end.(I know the OS won't get updates...) I just installed the latest Oracle update. It purged almost every fs2 dependency I had installed. gcc, libopenal,... all gone. Also, the update errata was deleted from oracle.com!
I wouldn't say the endianness bug was a Solaris issue. Our macros/functions like SWAP_FLOAT and INTEL_INT only work for the 4/5 platforms we support(Windows/x86, Linux/x64, Linux/x86, OSX/ppc, and OSX/x86). Every other platform I've played with somehow leaked STWBRX into the mix.
While I'm here I'd like to point out that STWBRX cannot store to a register, so if you're really worried about speed, and only doing it a few times, you might be better off using some simple bitshifting. Has anyone done benchmarks on it?
So, where do I get these asteroids?
-
Sorry I didn't mean that it's a Solaris bug, just that different behavior is experienced on Solaris. Where the bug is, I wouldn't know. Asteroids are coming :P
-
So, it works!
Touchy parts:
- The big-endian vs. little endian macro mess wasn't working for floats, so all the models crashed. Currently my version will only work on Solaris/x86. What we need, is better detection of what endianness we're using
- The configure script PKG_CHECK_MODULES doesn't work and has to be patch by hand right now
- if you run with LANG set, you'll get a weird xerror, followed by a segfault. Do we use LANG right now?
http://rsaxvc.net/blog/doku.php?id=building_fs2_on_solaris (http://rsaxvc.net/blog/doku.php?id=building_fs2_on_solaris) has been update accordingly.
[attachment deleted by admin]
-
I don't think we use LANG, not certain. Grep would probably know.
If Sun Lua is lacking features, could we use the Lua that's in the code base already?
Edit: Patch of some of the changes you mentioned in the blog post is available (http://swc.fs2downloads.com/files/solaris_fixes.diff).
-
Yep, it works pretty well. I can make you a nice diff if you like.
Also, I got the old HP-UX box running, with OpenGL.
We could add a call to unsetenv("LANG"); before SDL init.
-
Ok, we've already committed the 'sun' var renaming stuff to trunk, but I took some of your other changes and tweaked some things. What could you do with this patch (http://swc.fs2downloads.com/files/solaris_fixes_v2.diff), rsa? I thought creating a SCP_SOLARIS define might be useful, unless you know another equivalent define that would already exist for use in the code. But I used it to wrap the filio include, because apparently including it will break every other platform besides Solaris since they don't split out ioctl into different includes.
-
SCP_SOLARIS is probably the way to go.
However, all of that work was done with OpenSolaris. I recently started playing with Oracle Solaris, which has some differences.
-
I have a feeling the filio stuff will still apply on Solaris. Have you gotten it running on that platform yet?
-
Yep, filio stuff still applies for oracle solaris.
The current problem is 3fold- Oracle Solaris ships with a slightly outdated version of OpenGL (OpenSolaris is up to date); however, OpenSolaris only supports the XVR-100 video card, which is not very fast( And I don't have one) on SPARC PCI systems. So normally I would just patch together pieces of each OS until it ran...but Oracle Sparc Solaris uses a different X implementation, XSUN, instead of XORG (which everything else uses), so you can't just copy modules around.
-
By copying bits from Solaris/x86/nvidia, I got it compiling and linking. However, launching responds with an error about missing GL_ARB_multitexture, which the XVR-600 video card does not support.
I did find this document from sun, which has a big table of cards and features:http://www.sun.com/software/graphics/opengl/1.3/SolImpPerfGuide1.3.pdf (http://www.sun.com/software/graphics/opengl/1.3/SolImpPerfGuide1.3.pdf)
That being said, I might be in the market for http://cgi.ebay.com/Sun-Microsystems-XVR-1200-graphics-card-XVR1200-/360300135537?pt=PCC_Video_TV_Cards&hash=item53e38fc471 (http://cgi.ebay.com/Sun-Microsystems-XVR-1200-graphics-card-XVR1200-/360300135537?pt=PCC_Video_TV_Cards&hash=item53e38fc471) or http://cgi.ebay.com/Sun-XVR-100-graphics-card-X3770A-375-3181-/190458920050?pt=PCC_Video_TV_Cards&hash=item2c583c7c72 (http://cgi.ebay.com/Sun-XVR-100-graphics-card-X3770A-375-3181-/190458920050?pt=PCC_Video_TV_Cards&hash=item2c583c7c72)
Unless multitexturing is something we could compile-switch out, but I really doubt that it is.
-
The Blade has a XVR-100 already right? I was thinking about getting the XVR-2500 (http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=200514623375&ssPageName=STRK:MEWAX:IT) myself. Want to see how the Blade runs first though. Does this (http://blogs.sun.com/alanc/entry/xorg_7_2_solaris_status) affect the Xorg situation on Solaris for you?
-
The blades came with XVR-600s, which are better than XVR-100s. XVR-2500s are pretty awesome, but PCIE only.
If I want to go for OpenSolaris/SPARC, I should buy an XVR-100
If I want to continue with Oracle Solaris/SPARC, I should buy an XVR-1200
-
I went with the XVR-1200. It was cheaper and does more OpenGL ops, although unsupported on OpenSolaris.
I almost wonder if porting the ATI OpenSource driver over to OpenSolaris would be the thing to do. You'd still need at least one Sun video card to access OpenBoot ( maybe not, if you plan on not reconfiguring your system once it is set up), but after that, Xorg should be good to go. Hopefully, this solution would support PCIE cards easily enough going forward.
Newegg has a one that is kinda expensive for what it is:
http://www.newegg.com/Product/Product.aspx?Item=N82E16814129063 (http://www.newegg.com/Product/Product.aspx?Item=N82E16814129063)
I've never ported a driver though, so it might be fun.
edit: fixed link / misread hcl
-
You can probably just hook up an old laptop over serial if you need to get to the boot console. You get control sooner then anyway.