Re: Cross compile errors with i686-w64-mingw32

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 28.07.2014 19:33, schrieb LRN:
> On 28.07.2014 20:42, Mario Reichel wrote:
>> Am 28.07.2014 17:51, schrieb LRN:
>>> On 28.07.2014 19:19, Mario Reichel wrote:
>>>> After this i tried to compile gtk+ 3.13.5 with ./configure 
>>>> --host=i686-w64-mingw32 --prefix=/home/mario/build32 and
>>>> environment variables CC, CXX und PKG_CONFIG_LIBDIR set.
>>> 
>>>> On make i get the following and many more (error logfile is
>>>> nearly 500kb)
>>> 
>>>> In file included from 
>>>> /home/mario/build32/include/glib-2.0/glib/glist.h:32:0, from
>>>>  /home/mario/build32/include/glib-2.0/glib/ghash.h:33, from 
>>>> /home/mario/build32/include/glib-2.0/glib.h:50, from 
>>>> extract-strings.c:18: 
>>>> /home/mario/build32/include/glib-2.0/glib/gmem.h: In function
>>>>  ‘__declspec’:
>>>> /home/mario/build32/include/glib-2.0/glib/gmem.h:293:10: 
>>>> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>>>> before ‘GMemVTable’ GLIB_VAR GMemVTable
>>>> *glib_mem_profiler_table; ^
>>> 
>>> Try `make V=1 -j1`, dump output into a file, inspect the file,
>>> find the gcc invocation that failed, copy it, cd into the build
>>> directory where the failure occurred (i.e. where
>>> extract-strings is being built), paste the gcc invocation
>>> command, edit it by adding a '-E' flag and changing the output
>>> filename to something else (instead of .o or whatever it is), 
>>> then look at the output file. It will contain preprocessed
>>> source code. Look for glib_mem_profiler_table declaration, see
>>> what happened to it after preprocessing.
>>> 
> 
>> I get this:
> 
>> typedef struct _GMemVTable GMemVTable;
> 
>> [ ... ]
> 
>> # 272 "/home/mario/build32/include/glib-2.0/glib/gmem.h" struct 
>> _GMemVTable { gpointer (*malloc) (gsize n_bytes); gpointer
>> (*realloc) (gpointer mem, gsize n_bytes); void (*free) (gpointer
>> mem);
> 
>> gpointer (*calloc) (gsize n_blocks, gsize n_block_bytes);
>> gpointer (*try_malloc) (gsize n_bytes); gpointer (*try_realloc)
>> (gpointer mem, gsize n_bytes); }; extern void g_mem_set_vtable
>> (GMemVTable *vtable); extern gboolean g_mem_is_system_malloc
>> (void);
> 
>> extern __declspec(dllimport) gboolean g_mem_gc_friendly;
> 
> 
>> extern __declspec(dllimport) GMemVTable *glib_mem_profiler_table;
>> extern void g_mem_profile (void);
> 
> 
>> # 33 "/home/mario/build32/include/glib-2.0/glib/glist.h" 2 # 1 
>> "/home/mario/build32/include/glib-2.0/glib/gnode.h" 1 # 34 
>> "/home/mario/build32/include/glib-2.0/glib/gnode.h"
> 
> 
>> typedef struct _GNode GNode;
> 
> The code looks correct. My guess is that something's wrong with the
> toolchain. Google for "in function __declspec" and "cross", this is
> outside of my area of experience.

Oh, one stap back ... make will start this command in the folder util:

make[2]: Betrete Verzeichnis '/home/mario/libs/win32/gtk+-3.13.5/util'
gcc   -mms-bitfields -I/home/mario/build32/include/glib-2.0
-I/home/mario/build32/lib/glib-2.0/include   -g -O2 extract-strings.c
 -L/home/mario/build32/lib -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
-lintl    -o extract-strings.exe

I think thats wrong that he would build a linux binary with the cross
compiled libs. If i lat them ignore this folger, later it says:

/bin/bash: Zeile 1: ../util/extract-strings: Datei oder Verzeichnis
nicht gefunden (file or folder not found)

So i think its a bug that he will cross compile a util like all other,
use the gnu-linux compiler und will use the result later for processing.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list





[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux