The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
December 08, 2024, 07:07:10 am
Home Help Search Login Register
News: Celebrating 30 years of Star Control 2 - The Ur-Quan Masters

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  trouble building on OS X
« previous next »
Pages: [1] 2 Print
Author Topic: trouble building on OS X  (Read 4539 times)
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
trouble building on OS X
« on: May 02, 2003, 07:39:37 am »

I just CVS checked out.
executed build, and set the directory for the build. Many warnings later, I got this error. Then, I re-ran, and immediately got the same error. Why does the installer neglect to provide an input file here?

> ./build.sh uqm
gcc -o obj/debug/./src/sc2code/libs/graphics/sdl/3do_blt.o -c  -I/sw/include/SDL -D_THREAD_SAFE -I/sw/include/SDL -D_THREAD_SAFE -g -O0 -W -Wall -DDEBUG_TRACK_SEM -DGFXMODULE_SDL -DSOUNDMODULE_SDL  -I src -I src/sc2code -I src/sc2code/libs
gcc: no input files
make: *** [obj/debug/./src/sc2code/libs/graphics/sdl/3do_blt.o] Error 1

What can I do about this?
Logged
Nic.
Guest


Email
Re: trouble building on OS X
« Reply #1 on: May 02, 2003, 07:55:21 am »

My only experience with building UQM under OSX was with 10.1.x, and according to some of your more recent shenanigans in Bugzilla, you're using 10.2.x, but your situation looks eerily familiar.

When using the 10.1.x dev tools, "gcc -MM" did not output the correct commands, which caused "build.sh uqm depend" to create bad Makefiles, which in turn caused everything to completely freak out.  Creative use of Perl got me out of that ditch, and ultimately I was able to get a working binary (OpenAL notwithstanding), but my wife has long since banned me from her iBook, so that work is lost  Wink

Depending on how "fresh" your dev tool kit is, you may have the same problem; the solution would be to get the latest+greatest dev tools from Apple, or hack up something to get "build.sh uqm depend" to generate working Makefiles.  I honestly wish I could be of more help here.
Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #2 on: May 02, 2003, 09:22:23 am »

"shenanigans" hmph

In any case, since you got it working before, can you point me in the right direction on the perl hack that made it work? Perhaps use the 'sudo'-like 'wifedo' system ("Dear, could you email me /usr/local/games/sc2/fix.perl ??")
Wink

I'll try updating the dev tools. If I can build it, should I send it over to you so it can be hosted, even if it's not a finder executable?
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: trouble building on OS X
« Reply #3 on: May 02, 2003, 07:36:07 pm »

If you abort the dependency making, you may be stuck with bad .depend files. Try 'rm .depend.*' or './buils.sh uqm clean' and build again.

Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
Nic.
Guest


Email
Re: trouble building on OS X
« Reply #4 on: May 02, 2003, 08:56:54 pm »

Quote
In any case, since you got it working before, can you point me in the right direction on the perl hack that made it work?

The problem is pretty straightforward:  "gcc -MM" is supposed to generate a suitable make rule for the given file.  On OSX, it kindof sortof "forgets" to include the name of the file you passed in :-/, but the remainder of the rule is OK.  So all you need to do is tinker with the output of "gcc -MM" so that the filename that you originally pass in is included with the output.  I used Perl in this case because I was dealing with Unix filenames, which have "/" characters in them, which sed insisted on using as a pattern delimiter.  After fighting with sed for a while, I just used Perl because it lets you pick your own pattern delimiters (and that box had alot of RAM anyways Smiley)  But I think the newest dev tools have a properly-functioning gcc, rendering this issue moot.

Quote
I'll try updating the dev tools. If I can build it, should I send it over to you so it can be hosted, even if it's not a finder executable?

I'd prefer if it was a .app file, but executables inside .apps are easy enough to replace.  Send me a private message on this forum, or look for me on #sc2 via IRC to coordinate.
« Last Edit: May 02, 2003, 09:01:04 pm by Nic. » Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #5 on: May 02, 2003, 09:02:15 pm »

No shit, you can just replace the executable and the app works? Hrm... I'd be on top of it, but my browser decided to download all but the last byte of the dev tools. I hate when that happens.
Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #6 on: May 02, 2003, 11:10:12 pm »

Ohkay, the new dev tools came up with this:

Code:

> build.sh uqm
Sed stream editor found.
tr found.
Make found.
GNU C compiler found.
Big-endian machine.
Simple DirectMedia Layer not found.


It's there, installed in /usr/local/lib, right next to all the others and where it used to be. It found it before, any idea what's going wrong now?
Logged
Nic.
Guest


Email
Re: trouble building on OS X
« Reply #7 on: May 02, 2003, 11:32:21 pm »

The build scripts run "sdl-config" to figure out what they are doing with regards to SDL.  If that script went AWOL, is not in your path, or lost its execute bits, then you'll get this error even if SDL is otherwise properly installed.

Try running "sdl-config --version" from a command prompt to see if it's actually working.  Beyond that, I remember there being some weird issue with SDL having its own function called main(), and OSX getting really cranky when it tried to compile a test program for SDL whose main() function didn't match that prototype; but I thought those issues were fixed a while back.

A good thing to do when things go bad is to edit the build/unix/config_functions file so that the BUILDLOG variable points to somewhere other than /dev/null; then you can read the log of what the builds were trying to do (until this game gets out of alpha, that variable should point to a regular file anyhow, IMHO) and get a clearer idea of what's going wrong.
Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #8 on: May 03, 2003, 02:51:44 am »

here is my complete install log:

Code:

gcc /tmp/build.15888.tmp.c -o /tmp/build.15888.tmp.out
gcc -I/sw/include/SDL -D_THREAD_SAFE -L/sw/lib -lSDLmain -lSDL -framework Cocoa
-framework OpenGL /tmp/build.15888.tmp.c -o /tmp/build.15888.tmp.out
ld: multiple definitions of symbol _main
/sw/lib/libSDLmain.a(SDLMain.o) definition of _main in section (__TEXT,__text)
/var/tmp//ccSokiM2.o definition of _main in section (__TEXT,__text)


this is after making clean. I suspect that I'm stuck in the middle of a build since the first compilation is out of /tmp...
here we have ld complaining about multiple definitions of main, but I don't know that that would make it say that SDL doesn't EXIST.

Oh, and your suggestion of calling "sdl-config --version" returned "1.2.5", so it looks like it's installed properly.
« Last Edit: May 03, 2003, 02:52:07 am by Death_999 » Logged
Nic.
Guest


Email
Re: trouble building on OS X
« Reply #9 on: May 03, 2003, 04:24:54 am »

I guess I am mistaken -- You are getting bitten by the multiple-definitions-of-main bug on OS X.  This causes the compilation of the test program to fail, which the build scripts interpret as SDL not existing (because it's program to test for the existance of SDL failed, naturally)

If I recall correctly, the problem isn't that you have two main() functions, but that you've (implicitly) defined two prototypes for main().  I remember kludging in a "special" test program for SDL that had a different main() function to match SDL's prototype, but that is probably not the ideal solution.

As I'm sure you can tell by now, the OS X support for the game has got quite a few rough edges at this point.  If you get out of the ditch on this one, please please PLEASE submit your changes to the project via Bugzilla.

Edit: try this: in the file build/unix/config_functions, replace all instances of "int main()" with "int main(int argc, char *argv[])"  I think that will cure your woes, and not ruin anyone else's day either.
« Last Edit: May 03, 2003, 08:10:04 am by Nic. » Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #10 on: May 04, 2003, 02:07:22 am »

well, I don't have a build/unix/ directory, but I do have a build/config_functions file in build/

making the changes you suggested...
build.sh uqm clean
build.sh uqm
...
no change.
Logged
Nic.
Guest


Email
Re: trouble building on OS X
« Reply #11 on: May 04, 2003, 09:14:55 am »

What version are you trying to build?  The directory structure you have is not "current CVS"

Try "cvs -z6 update -d -P" in the toplevel directory for your UQM sources, if you've got a CVS version of the sources.  Your problems may just correct themselves after you do.

If you do not have a CVS version of the sources, may I direct you to a fine document that details how to obtain them?  Smiley

For the record, I am stumped, unless you want to give me login access to your box and let me slap around your builds a bit.  If you consider this a viable option, email me with the details.
Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #12 on: May 05, 2003, 09:04:14 pm »

Hrm.. Well, just before compiling I executed the command
cvs -z6 -d (insert url here) checkout sc2

I guess that works for initial download but not updating?

weird -- I am no longer able to explicitly log in to the CVS server without a password.

Furthermore, there was a bit of a mess trying to update. It took me three tries to get the update to work in the project home, but I managed to update the src and build directories independently.

after the update:
> build.sh uqm install
Sed stream editor found.
tr found.
Make found.
GNU C compiler found.
Big-endian machine.
Simple DirectMedia Layer not found.

hmm... I made the changes suggested again... same result.

As far as logging in... well, the firewall is kind of picky about that.
« Last Edit: May 05, 2003, 10:57:38 pm by Death_999 » Logged
mhildum
Zebranky food
*
Offline Offline

Posts: 3


I love YaBB 1G - SP1!


View Profile
&
« Reply #13 on: May 15, 2003, 09:15:42 am »

I am pretty new at this so please ignore this if it is way off Smiley

I was having the same problem initially, even though the file was in /usr/local/bin

after adding that to my path I was able to get farther in the build... but still not complete.  I used-

set env PATH ${PATH}:/usr/local/bin

in order to add it to my path.  Afterwards I was able to build farther.. and even get to the build menu.. however havent been able to finish compiling.  I can't seem to get the SDL_IMAGE installed properly..
« Last Edit: May 15, 2003, 09:17:19 am by mhildum » Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3874


We did. You did. Yes we can. No.


View Profile
Re: trouble building on OS X
« Reply #14 on: May 15, 2003, 08:06:38 pm »

what file was in /usr/local/bin? There are LOTS of files in /usr/local/bin...
Logged
Pages: [1] 2 Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!