UFO:Alien Invasion

Development => Newbie Coding => Topic started by: Muton on April 17, 2010, 11:29:31 am

Title: compile using MinGW
Post by: Muton on April 17, 2010, 11:29:31 am

I tried it today

1)
lets say a user simply dont care about file naming
and created a folder called "strün (x68)"
than make will fail
 * [GAM] src/game/inventory.c
 * [GAM] ... linking -rdynamic ()
gcc.exe: unrecognized option '-rdynamic'
/bin/sh: -c: line 1: syntax error near unexpected token `('
/bin/sh: -c: line 1: `  gcc -g -O2 -DUFO_REVISION=\"27318:29330M\"  -DGETTEXT_STATIC -DWINVER=0x501 -DSHARED_EXT=\"dll\" -DHAVE_CONFIG_H -DUSE_SIGNALS=1 -Wall -pipe -Winline -Wcast-qual -Wcast-align -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -std=c99 -ggdb -O0 -DDEBUG -fno-inline -DLUA_USE_APICHECK -DCOMPILE_UFO -D_GNU_SOURCE=1 -Dmain=SDL_main -IV:/STRN(X~1/MinGW/include/SDL   -o debug-mingw32-i386/client/client/cl_console.o -c src/client/cl_console.c -MD -MT debug-mingw32-i386/client/client/cl_console.o -MP'
make: *** [debug-mingw32-i386/client/client/cl_console.o] Error 2

2)
If the user named the folder whatever but not foo(bar)
make failed
 * [GAM] src/game/g_actor.c
 * [GAM] src/game/g_ai.c
........
 * [GAM] src/game/q_shared.c
 * [GAM] src/game/inv_shared.c
 * [GAM] src/game/inventory.c
 * [GAM] ... linking -rdynamic ()
gcc.exe: unrecognized option '-rdynamic'
 * [UFO] src/client/cl_console.c
 * [UFO] src/client/cl_game.c
 * [UFO] src/client/cl_game_campaign.c
 * [UFO] src/client/cl_game_multiplayer.c
...
 * [UFO] src/client/input/cl_keys.c
 * [UFO] src/client/cinematic/cl_cinematic.c
 * [UFO] src/client/cinematic/cl_cinematic_roq.c
 * [UFO] src/client/cinematic/cl_cinematic_ogm.c
src/client/cinematic/cl_cinematic_ogm.c:17:2: error: #error "No ogm support compiled into the binary"
make: *** [debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o] Error 1

Title: Re: compile using MinGW
Post by: Mattn on April 17, 2010, 11:52:32 am

strange

Code: [Select]

#define HAVE_VORBIS_CODEC_H 1
#define HAVE_XVID_H 1
#define HAVE_THEORA_THEORA_H 1

should be in your config.h (according to your config.log)

this file should be included because you have -DHAVE_CONFIG_H defined as gcc option.

and the error should only appear if the above missing variables are missing...

Title: Re: compile using MinGW
Post by: Muton on May 09, 2010, 12:29:02 pm

(http://www.websmileys.com/sm/aliens/17.gif)
refering to
http://ufoai.ninex.info/forum/index.php?topic=4768.0

make models
will only succeed if make was called once
if not

Code: (mingw shell) [Select]

* [MOD] src/tools/ufomodel/ufomodel.c
Assembler messages:
Fatal error: can't create debug-mingw32-i386/tools/ufomodel/tools/ufomodel/ufomodel.o: No such file or directory
there is no debug-mingw32-i386 folder
and cc1.exe will just hang forever (need to kill it)

ufomodel.exe
will cry for libpng12.dll but there is only libpng12-0.dll in contrib/dlls (copy of libpng12-0.dll named libpng12.dll will work)
C::B build will run as expected
You should force a recompile of ufomodel.exe
to be sure its not an old build, C::B build or whatever

make pk3

Code: (mingw shell) [Select]

/bin/sh: zip: command not found
make[1]: *** [base/0pics.pk3] Error 127
make[1]: Leaving directory `/ufoai'
make: *** [pk3] Error 2
there was and is no zip tool in mingw bin (7z?)

Title: Re: compile using MinGW
Post by: Mattn on May 09, 2010, 01:16:03 pm

strange - for mingw32 7za should be used - maybe wrong inclusion order of build/data.mk

Title: Re: compile using MinGW
Post by: Muton on May 09, 2010, 01:39:50 pm

#error "No ogm support compiled into the binary" problem
used verbose output
first i've used
--prefix=
during config but gcc output is
configure --prefix=/mingw
and than no compiler option HAVE_VORBIS_CODEC_H HAVE_XVID_H HAVE_THEORA_THEORA_H
attached config.h
lot of undef

Code: [Select]

* [UFO] src/client/cinematic/cl_cinematic_ogm.c
Using built-in specs.
Target: mingw32
Configured with: ../../gcc-4.4.1/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls --disable-win32-registry --enable-libgomp --enable-cxx-flags='-fno-function-sections -fno-data-sections' --disable-werror --enable-threads --disable-symvers --enable-version-specific-runtime-libs --enable-fully-dynamic-string --with-pkgversion='TDM-2 mingw32' --enable-sjlj-exceptions --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php
Thread model: win32
gcc version 4.4.1 (TDM-2 mingw32)
COLLECT_GCC_OPTIONS='-v' '-g' '-O2' '-DUFO_REVISION="27318:29824M"' '-DGETTEXT_STATIC' '-DWINVER=0x501' '-DSHARED_EXT="dll"' '-DHAVE_CONFIG_H' '-DUSE_SIGNALS=1' '-Wall' '-pipe' '-Winline' '-Wcast-qual' '-Wcast-align' '-Wdeclaration-after-statement' '-Wmissing-prototypes' '-Wmissing-declarations' '-std=c99' '-ggdb' '-O0' '-DDEBUG' '-fno-inline' '-DLUA_USE_APICHECK' '-DCOMPILE_UFO' '-D_GNU_SOURCE=1' '-Dmain=SDL_main' '-IV:/str/MinGW/include/SDL' '-o' 'debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o' '-c' '-MD' '-MT' 'debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o' '-MP' '-mtune=i386'
 v:/str/mingw/bin/../libexec/gcc/mingw32/4.4.1/cc1.exe -quiet -v -IV:/str/MinGW/include/SDL -iprefix v:\str\mingw\bin\../lib/gcc/mingw32/4.4.1/ -MD debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.d -MP -MT debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o -DUFO_REVISION="27318:29824M" -DGETTEXT_STATIC -DWINVER=0x501 -DSHARED_EXT="dll" -DHAVE_CONFIG_H -DUSE_SIGNALS=1 -DDEBUG -DLUA_USE_APICHECK -DCOMPILE_UFO -D_GNU_SOURCE=1 -Dmain=SDL_main src/client/cinematic/cl_cinematic_ogm.c -quiet -dumpbase cl_cinematic_ogm.c -mtune=i386 -auxbase-strip debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o -g -ggdb -O2 -O0 -Wall -Winline -Wcast-qual -Wcast-align -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -std=c99 -version -fno-inline -o - |
 v:/str/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/as.exe -o debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o
ignoring nonexistent directory "v:\str\mingw\bin\../lib/gcc/mingw32/4.4.1/../../../../mingw32/include"
ignoring duplicate directory "v:/str/mingw/lib/gcc/../../include"
ignoring duplicate directory "v:/str/mingw/lib/gcc/../../lib/gcc/mingw32/4.4.1/include"
ignoring duplicate directory "v:/str/mingw/lib/gcc/../../lib/gcc/mingw32/4.4.1/include-fixed"
ignoring nonexistent directory "v:/str/mingw/lib/gcc/../../lib/gcc/mingw32/4.4.1/../../../../mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 V:/str/MinGW/include/SDL
 v:\str\mingw\bin\../lib/gcc/mingw32/4.4.1/../../../../include
 v:\str\mingw\bin\../lib/gcc/mingw32/4.4.1/include
 v:\str\mingw\bin\../lib/gcc/mingw32/4.4.1/include-fixed
 /mingw/lib/gcc/mingw32/4.4.1/../../../../include
End of search list.
GNU C (TDM-2 mingw32) version 4.4.1 (mingw32)
        compiled by GNU C version 4.4.1, GMP version 4.3.0, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: cf55188e7d2f640bec71afc62bf8d59d
src/client/cinematic/cl_cinematic_ogm.c:17:2: error: #error "No ogm support compiled into the binary"
make: *** [debug-mingw32-i386/client/client/cinematic/cl_cinematic_ogm.o] Error 1


Title: Re: compile using MinGW
Post by: Muton on May 20, 2010, 08:21:49 pm

./configure --prefix= --exec-prefix=
........
checking for jpeglib.h... yes
checking for jpeg_CreateDecompress in -ljpeg... yes
configure: error: For current build options, pkg-config is required. Did you maybe forget to run aclocal with the current include path?

--------------------------------

ufomodel.exe
will cry for libpng12.dll but there is only libpng12-0.dll in contrib/dlls

The problem is libpng12.dll.a referring to libpng12.dll instead of libpng12-0.dll
I've recompiled png and now its working
C::B is using libpng3 (older) btw because of png instead of png12
What about version 1.4??

Title: Re: compile using MinGW
Post by: Mattn on May 20, 2010, 08:55:29 pm

i'm using 1.4 on linux - so feel free to update the c::b script and/or package

Title: Re: compile using MinGW
Post by: Muton on May 21, 2010, 11:47:03 am

I was able to "make" under mingw

I had to edit
mingw/bin/sdl-config
modify line 3 to
prefix=

and after "configure" modify
ufoai/config.h
each line
#undef HAVE_VORBIS_CODEC_H
#undef HAVE_XVID_H
#undef HAVE_THEORA_THEORA_H
to
#define HAVE_VORBIS_CODEC_H
#define HAVE_XVID_H
#define HAVE_THEORA_THEORA_H
to fix cl_cinematic_ogm.c "No ogm support compiled into the binary"

if i configure some CFLAGS then the value is NOT appended (Makefile)
CFLAGS=-v
instead of
CFLAGS=-g -O2 -v

Windows 2000
I had to edit (WINVER 0x500)
platform_specific.mk
or
config.h
to compile the game for Windows 2000
but it will fail during net.c
btw no problem under C::B

Code: [Select]

COLLECT_GCC_OPTIONS='-g' '-O2' '-v' '-DUFO_REVISION="27318:30088M"' '-DGETTEXT_STATIC' '-DWINVER=0x500' '-DSHARED_EXT="dll"' '-DHAVE_CONFIG_H' '-DUSE_SIGNALS=1' '-Wall' '-pipe' '-Winline' '-Wcast-qual' '-Wcast-align' '-Wdeclaration-after-statement' '-Wmissing-prototypes' '-Wmissing-declarations' '-std=c99' '-ggdb' '-O0' '-DDEBUG' '-fno-inline' '-DLUA_USE_APICHECK' '-DCOMPILE_UFO' '-IV:/str/MinGW/include/SDL' '-D_GNU_SOURCE=1' '-Dmain=SDL_main' '-o' 'debug-mingw32-i386/client/ports/windows/win_main.o' '-c' '-MD' '-MT' 'debug-mingw32-i386/client/ports/windows/win_main.o' '-MP' '-mtune=i386'
 * [RC ] src/ports/windows/ufo.rc
 * [UFO] ... linking   (-LV:/str/MinGW/lib -lvorbis -lm -logg       -lz  -L/usr/local/lib -lcurl -L/home/dast/src/win32 -lwinmm -lws2_32 -lz -lws2_32 -ljpeg  -LV:/str/MinGW/lib -lpng12   -L/lib -lmingw32 -lSDLmain -lSDL -mwindows -lSDL_image  -lSDL_mixer  -lSDL_ttf  -logg  -lxvidcore  -LV:/str/MinGW/lib -ltheora -logg   -lintl -lxvidcore  -lws2_32 -lwinmm -lopengl32 -L/lib -lmingw32 -lSDLmain -lSDL -mwindows)
debug-mingw32-i386/client/common/net.o: In function `NET_Connect':
V:\str\MinGW\ufoai/src/common/net.c:630: undefined reference to `WspiapiGetAddrInfo@16'
V:\str\MinGW\ufoai/src/common/net.c:639: undefined reference to `WspiapiFreeAddrInfo@4'
V:\str\MinGW\ufoai/src/common/net.c:645: undefined reference to `WspiapiFreeAddrInfo@4'
debug-mingw32-i386/client/common/net.o: In function `NET_StreamPeerToName':
V:\str\MinGW\ufoai/src/common/net.c:822: undefined reference to `WspiapiGetNameInfo@28'
debug-mingw32-i386/client/common/net.o: In function `SV_Start':
V:\str\MinGW\ufoai/src/common/net.c:927: undefined reference to `WspiapiGetAddrInfo@16'
V:\str\MinGW\ufoai/src/common/net.c:941: undefined reference to `WspiapiFreeAddrInfo@4'
debug-mingw32-i386/client/common/net.o: In function `NET_DatagramSocketNew':
V:\str\MinGW\ufoai/src/common/net.c:1048: undefined reference to `WspiapiGetAddrInfo@16'
V:\str\MinGW\ufoai/src/common/net.c:1059: undefined reference to `WspiapiFreeAddrInfo@4'
debug-mingw32-i386/client/common/net.o: In function `NET_SockaddrToStrings':
V:\str\MinGW\ufoai/src/common/net.c:1146: undefined reference to `WspiapiGetNameInfo@28'
debug-mingw32-i386/client/common/net.o:net.c:(.data+0x8): undefined reference to `WspiapiLegacyGetAddrInfo@16'
debug-mingw32-i386/client/common/net.o:net.c:(.data+0x10): undefined reference to `WspiapiLegacyGetNameInfo@28'
debug-mingw32-i386/client/common/net.o:net.c:(.data+0x18): undefined reference to `WspiapiLegacyFreeAddrInfo@4'
debug-mingw32-i386/client/common/net.o:net.c:(.rdata+0x834): undefined reference to `WspiapiLegacyGetAddrInfo@16'
debug-mingw32-i386/client/common/net.o:net.c:(.rdata+0x83c): undefined reference to `WspiapiLegacyGetNameInfo@28'
debug-mingw32-i386/client/common/net.o:net.c:(.rdata+0x844): undefined reference to `WspiapiLegacyFreeAddrInfo@4'
collect2: ld returned 1 exit status
make: *** [ufo] Error 1


Title: Re: compile using MinGW
Post by: Mattn on May 23, 2010, 12:34:07 pm

thanks for sharing this info - i will give it a try later with cross-compiling, too

Title: Re: compile using MinGW
Post by: Muton on May 27, 2010, 12:25:43 pm

On Windows there is a problem related to stdout
all output is redirected to a text file called stdout/stderr.txt
and no output on the console
Very annoying!
How can I get console output instead of stdout.txt and stderr.txt
http://sdl.beuc.net/sdl.wiki/FAQ_Console

ufo2map and ufomodel is affected if compiled under Mingw
ufo2map is working well if compiled using C::B
ufomodel will use txt files even when C::B

I've focused on ufo2map first
conclusion
Linking:
$(filter-out -lmingw32 -lSDLmain -mwindows,$(TOOLS_LIBS)) $(filter-out -lmingw32 -lSDLmain -mwindows,$(SDL_LIBS))
build .o
$(filter-out -Dmain=SDL_main,$(SDL_CFLAGS))

But i dont know how to merge this into tools.mk, except to use a new var (this will effect any OS_build)
# Say how to link the exe
$(UFO2MAP_TARGET): $(UFO2MAP_OBJS)
   @echo " * [MAP] ... linking $(LNKFLAGS) ( $(filter-out -lmingw32 -lSDLmain -mwindows,$(TOOLS_LIBS)) $(filter-out -lmingw32 -lSDLmain -mwindows,$(SDL_LIBS)) )"; \
      $(CC) $(LDFLAGS) -o $@ $(UFO2MAP_OBJS) $(filter-out -lmingw32 -lSDLmain -mwindows,$(TOOLS_LIBS)) $(filter-out -lmingw32 -lSDLmain -mwindows,$(SDL_LIBS)) $(LNKFLAGS)
....
# Say how to build .o files from .c files for this module
# -ffloat-store option to ensure that maps are the same on every plattform
# store the float values in buffers, not in cpu registers, maybe slower
$(BUILDDIR)/tools/ufo2map/%.o: $(SRCDIR)/%.c
   @echo " * [MAP] $<"; \
      $(CC) $(UFO2MAP_CFLAGS) $(filter-out -Dmain=SDL_main,$(SDL_CFLAGS)) -o $@ -c $< $(CFLAGS_M_OPTS)

Title: Re: compile using MinGW
Post by: Muton on September 14, 2010, 05:20:40 pm

I'm currently updating the MinGW environment
Because of this i try to update libpng too along with SDL (to clean up *.dlls)
and there i have a problem

Compiling SDL was easy but if i try to compile ufomodel using C::B
i run into a linking error
D:\temp\UFOAIwin32BUILDenv\MinGW\lib\libpng.a(libpng14_la-pngwrite.o):pngwrite.c|| undefined reference to `deflateEnd'| ...
Thats a zlib error?!
The problem is i need to add -lpng to compile ufomodel
-lSDLmain alone will cause this error

looking to libSDLmain.a resolve
that mine is only 4kb in size while the original is 200kb big
I can compile ufomodel under MinGW by the way

Title: Re: compile using MinGW
Post by: Mattn on September 14, 2010, 07:12:47 pm

add -lz - libpng needs libz (or zlib)

Title: Re: compile using MinGW
Post by: Muton on September 14, 2010, 07:31:03 pm

I did not read the manual ....
got it running :)

Title: Re: compile using MinGW
Post by: Muton on September 17, 2010, 12:09:47 pm

I've learned something today

I'm building SDL from source to reduce the amount of dlls we need to run our programs

This task is somewhat finished and i tried to build ufomodel
One time directly under MinGW and than using C::B
Under Mingw is everything working as expected
meaning every requested dll correspond to your libs
but under C::B we need to include "every" lib we need
If you dont include png12 || png14 ufomodel will cry for libpng3.dll
instead of libpng12-0.dll || libpng14-14.dll.
It seams to be some sort of fall-back for png if you dont include pngxx
even if you include png which refers to png12 || png14 ...
Meaning including png (-lpng) will result in libpng3.dll

Its confusing
SDL_image request png12 || png14
libpng request zlib
and ufomodel itslef need zlib && libpng
But you dont need to add zlib (-lz), but png(12||14)

This seams to be the reason why we need so much dlls

I've added png14 (because SDL_image was compiled against png14)
The result was that ufomodel.exe requests the same dlls as SDL_mixer.dll

Title: Re: compile using MinGW
Post by: bayo on September 17, 2010, 01:52:03 pm

Quote

I'm building SDL from source to reduce the amount of dlls

I really dont see the point. Nowhere it will be a gain.

Title: Re: compile using MinGW
Post by: Mattn on September 17, 2010, 02:40:55 pm

i'm using mingw-cross-env to cross compile everything and link statically - our build bot should deliver binaries that uses a lot less dlls.

Title: Re: compile using MinGW
Post by: Muton on September 18, 2010, 08:20:05 am

> link statically
Tried that too
but in that case i have to recompile a lot more libs

> build bot
Do you plan to share nightly builds?
I've found some files in contrib, but ...

Title: Re: compile using MinGW
Post by: bayo on September 18, 2010, 09:02:34 am

I think, yes, nightlybuild. But both buildbot config, and makefiles need changes. Then contrib content is not yet ready for it.

Title: Re: compile using MinGW
Post by: Mattn on September 18, 2010, 12:45:36 pm

i'm still working on the makefiles and the buildbot config - if someone wanna help, let me know and i can publish the patches. getting the buildbot to compile binaries for every supported architecture would be the goal.

Title: Re: compile using MinGW
Post by: Muton on September 23, 2010, 09:38:28 pm

I'm able to link libs statically for every tool except radiant (as expected)

undefined reference to `_imp__gtk_micro_version' (and a lot more .... and more .... much more ..... )
It should be in libgtk-win32-2.0.a
but the compiled (mingw-cross-env-2.15) libgtk-win32-2.0.a doesn't contain this function
A MinGW compiled shared libgtk-win32-2.0.dll.a contains this function  ???

I'm using

--start-group
-lgtkglext-win32-1.0
-lgdkglext-win32-1.0
-lgtk-win32-2.0
-lgdk-win32-2.0
-lgdk_pixbuf-2.0
-lgtksourceview-2.0
-lgthread-2.0
-lpangowin32-1.0
-lpangocairo-1.0
-lpango-1.0
-latk-1.0
-lcairo
-lgmodule-2.0
-lglib-2.0
-lgobject-2.0
-lxml2
-luser32
-lgdi32
-lshell32
-lkernel32
-lintl
-lopengl32
-lopenal32
-lvorbisfile
-lvorbis
-logg
-lfontconfig
-lpng14
-ltiff
-ljpeg
-lws2_32
-liconv
-lz
-lwinmm
--end-group

Title: Re: compile using MinGW
Post by: Mattn on September 23, 2010, 10:11:23 pm

check for special flags for configure here:

http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/100f824d2db1/src

Title: Re: compile using MinGW
Post by: Muton on September 25, 2010, 12:01:57 pm

Tried that already ;)

I than tried to build gtk+ on Win32 MinGW without success (its a pain)
than i've searched the root of the "problem"
and thats finally the solution (as dexcribed here (http://www.gtk.org/api/2.6/gtk/gtk-Feature-Test-Macros.html))

We need something >like< that
ufoai/src/tools/radiant/radiant/dialogs/about.cpp
Line: 130 && 140

Code: [Select]

#ifdef static
g_snprintf(versionString, sizeof(versionString), "%i.%i.%i", GTK_MAJOR_VERSION, GTK_MINOR_VERSION, GTK_MICRO_VERSION);
#else
g_snprintf(versionString, sizeof(versionString), "%i.%i.%i", gtk_major_version, gtk_minor_version, gtk_micro_version);
#endif
............
#ifdef static
g_snprintf(versionString, sizeof(versionString), "%i.%i.%i", GTKGLEXT_MAJOR_VERSION, GTKGLEXT_MINOR_VERSION, GTKGLEXT_MICRO_VERSION);
#else
g_snprintf(versionString, sizeof(versionString), "%i.%i.%i", gtkglext_major_version, gtkglext_minor_version, gtkglext_micro_version);
#endif


Title: Re: compile using MinGW
Post by: Mattn on September 25, 2010, 01:25:04 pm

why would that be needed? i mean, the if case - can't we just always use the macros from the headers?

Title: Re: compile using MinGW
Post by: Muton on September 25, 2010, 01:58:35 pm

You are right
radiant compiles even with dynamic libs

I was not sure ...

Edit

This tool is not ready to be linked statically
line 150 must also be edited
g_snprintf(versionString, sizeof(versionString), "%i.%i.%i", GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION, GLIB_MICRO_VERSION);


This function is only available on a shared lib (I give up!)
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0x8c0): undefined reference to `_imp__g_threads_got_initialized'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0x8cb): undefined reference to `_imp__g_thread_functions_for_glib_use'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0x92f): undefined reference to `_imp__g_thread_functions_for_glib_use'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xc76): undefined reference to `_imp__g_threads_got_initialized'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xc81): undefined reference to `_imp__g_thread_functions_for_glib_use'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xc9d): undefined reference to `_imp__g_threads_got_initialized'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xca8): undefined reference to `_imp__g_thread_functions_for_glib_use'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xcc6): undefined reference to `_imp__g_threads_got_initialized'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xcd1): undefined reference
 to `_imp__g_thread_functions_for_glib_use'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xd01): undefined reference to `_imp__g_threads_got_initialized'
.objs\radiant\src\tools\radiant\radiant\exec.o:exec.cpp:(.text+0xd0c): undefined reference to `_imp__g_thread_functions_for_glib_use'
.objs\radiant\src\tools\radiant\radiant\main.o:main.cpp:(.text+0x15f7): undefined reference to `_imp__g_threads_got_initialized'


even if i add every lib i have
i got tons of linker errors (http://www.planetsmilies.com/smilies/mad/mad0272.gif)

Title: Re: compile using MinGW
Post by: Mattn on September 26, 2010, 09:38:53 am

the g_threads is an own lib - are you sure you linked that one, too (should be part of the pkg-config file, if not, fix that file instead any linker flags)

Title: Re: compile using MinGW
Post by: Muton on September 26, 2010, 12:52:07 pm

-lgthread-2.0
Afak C::B dont care about pkg_config

You need a shared lib to get this function
its not available on a static lib (--enable-static --disable-shared)

Title: Re: compile using MinGW
Post by: Muton on November 07, 2010, 12:18:24 pm

There was/is a discussion going on about the same topic here (http://ufoai.ninex.info/forum/index.php?topic=5425.0)

Title: Re: compile using MinGW
Post by: Muton on November 07, 2010, 12:58:11 pm

I've made a new MinGW here (http://www.meduniwien.ac.at/user/michael.zellhofer/ufoai/UfoAI_win32_build_environment_0.3.1.exe)

copy your gitsource below mingw; or use /etc/fstab to link it into mingw (you'll the wont see the folder using ls)
run ....\MinGW\msys.bat
move to the gitsource
./configure --help

Python2.7, 3.1 and msysgit is included + tons of dll's (mingw/bin)
mapget.py will run
Radiant can be build only shared while any ufo(tool) can be build static (--enable-static)

Tip:
Useful make command
Q=
verbose output like Wall
-B
force recompile (C::B rebuild)
-n
just show commands but dont to anything else
-jn
run n jobs simultaneously -j2 2 jobs