The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
October 09, 2024, 08:00:55 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)
| | |-+  Some issues compiling with MINGW/MSYS
« previous next »
Pages: [1] Print
Author Topic: Some issues compiling with MINGW/MSYS  (Read 3721 times)
Juffo
Zebranky food
*
Offline Offline

Posts: 17



View Profile
Some issues compiling with MINGW/MSYS
« on: April 08, 2006, 08:49:04 pm »

1- I get the following error:
Code:
./config_win.h:45: error: stray '@' in program
c:/programmi/mingw/bin/../lib/gcc/mingw32/3.4.2/include/stddef.h:151: error: syntax error before "typedef"
the guilty line is simply
@HAVE_GETOPT_H@
I changed it to
#define HAVE_GETOPT_H
and it works. However:

2 - after running build.sh uqm config and setting to optimized release version the file size is 1.81 MB, almost the double than the release. Is the normal behavior of using MinGW?

3 - running "build.sh uqm config" I set to include OpenAL support (experimental) but then I get the following error:
Code:
  LINK     uqm
obj/release/src/sc2code/libs/sound/audiocore.c.o(.text+0x3c):audiocore.c: undefined reference to `openAL_Init'
collect2: ld returned 1 exit status
make: *** [uqm] Error 1
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #1 on: April 09, 2006, 01:30:30 am »

1. This was a problem when compiling on Windows with the Unix scripts. It's been fixed in CVS. Snapshots here.

2. What do you mean by "double than the release"?

3.  If you first compiled without OpenAL support, and later with, you should do a "./build.sh uqm clean" in between. Though just "./build.sh uqm depend" will probably work too, and will be faster.

Logged

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

Posts: 17



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #2 on: April 09, 2006, 06:53:40 am »

Quote
2. What do you mean by "double than the release"?
The original uqm.exe is 987 kb, the one built with minGW is 1.81 mb and when running doesn't output to console.

Quote
3.  If you first compiled without OpenAL support, and later with, you should do a "./build.sh uqm clean" in between. Though just "./build.sh uqm depend" will probably work too, and will be faster.
Ok, but now there's another problem:
Quote
In file included from src/sc2code/libs/sound/openal/audiodrv_openal.c:23:
src/sc2code/libs/sound/openal/audiodrv_openal.h:31:20: AL/al.h: No such file or directory
src/sc2code/libs/sound/openal/audiodrv_openal.h:32:21: AL/alc.h: No such file or directory
I can see those files are in the OpenAL library folder (.....\OpenAL\Include)
In the source tree, the file libs\sound\openal\audiodrv_openal.h says:

#if defined (__APPLE__)
#   include <OpenAL/al.h>
#   include <OpenAL/alc.h>
#else
#   include <AL/al.h>
#   include <AL/alc.h>
#   ifdef _MSC_VER
#      pragma comment (lib, "OpenAL32.lib")
#   endif
#endif

EDIT: solved by copying the needed files in the same folder of build.sh
« Last Edit: April 10, 2006, 07:03:15 am by Juffo » Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #3 on: April 09, 2006, 09:35:04 pm »

2. I knew that gcc build were larger, but not that they were that much larger. (I'm purely a Linux user myself)
3. Where were those file originally?

Logged

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

Posts: 17



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #4 on: April 10, 2006, 06:46:41 pm »

They aren't in the source tree at all. (release 0.50)
They are in the OpenAL include folder (e.g. c:\libs\OpenaL\Include) as part of the OpenAL SDK installation.

Quote
The original uqm.exe is 987 kb, the one built with minGW is 1.81 mb and when running doesn't output to console.
Quote
2. I knew that gcc build were larger, but not that they were that much larger. (I'm purely a Linux user myself)
Do I have to modify the source to get the console working?
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #5 on: April 10, 2006, 07:40:47 pm »

The OpenAL libs aren't supposed to be in the UQM source. They are however, supposed to be detected.
The console, you'll only get in debug mode, or if you set '--subsystem=console' in the environment var LDFLAGS before you run the uqm config.
Logged

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

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #6 on: April 10, 2006, 08:22:14 pm »

The OpenAL libs aren't supposed to be in the UQM source. They are however, supposed to be detected.
Clarification: the libraries are detected if they are installed properly; see the OpenAL SDK documentation for details.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Juffo
Zebranky food
*
Offline Offline

Posts: 17



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #7 on: April 10, 2006, 11:36:08 pm »

OK, thanks for the answers Smiley
Logged
fossil
Core Team
Frungy champion
*****
Offline Offline

Gender: Male
Posts: 94



View Profile
Re: Some issues compiling with MINGW/MSYS
« Reply #8 on: April 24, 2006, 01:43:41 pm »

2 - after running build.sh uqm config and setting to optimized release version the file size is 1.81 MB, almost the double than the release. Is the normal behavior of using MinGW?

Yes and no. The cygming special gcc (and ld) has a slightly different behavior than normal gcc. The doubling in size is the result of debug symbols not being stripped from the exe. This can be rectified by supplying --strip-debug or --strip-all flags to ld (or putting these values into LDFLAGS env var, like meep-eep said).
Now the real question is why gcc is producing these symbols in the first place, when no -g option specified.
Logged
Pages: [1] 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!