Some issues compiling with MINGW/MSYS

	Welcome, Guest. Please login or register. Did you miss your activation email? October 09, 2024, 08:00:55 am

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]

Author

Topic: Some issues compiling with MINGW/MSYS (Read 3721 times)

Juffo
Zebranky food

Offline

Posts: 17

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

Posts: 2847

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

Posts: 17

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

Posts: 2847

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

Posts: 17

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

Posts: 2847

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

Gender: Male

Posts: 1938

Fot or not?

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

Quote from: meep-eep 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.

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

Posts: 17

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

OK, thanks for the answers


	Logged

fossil
Core Team
Frungy champion

Offline

Gender: Male

Posts: 94

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

Quote from: Juffo on April 08, 2006, 08:49:04 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]

« previous next »