_imobiledevice for windows: compilation issues for ideviceinstaller

I finally succeed on the windows compilation.

compilation options

openssl:

LD=i586-mingw32msvc-ld AR=i586-mingw32msvc-ar CC="/opt/compiler/llvm31/bin/clang -target i386-pc-mingw32 -isysroot /opt/compiler/win" ./Configure mingw --prefix=/opt/compiler/win/

imobiledevice:

 LDFLAGS="-L/home/benoit/workspace/imobiledevice/binary/win/lib -lws2_32 -liberty -lole32 -lgdi32" CFLAGS=-I/home/benoit/workspace/imobiledevice/binary/win/include PKG_CONFIG_PATH="/opt/compiler/win/lib/pkgconfig/:/home/benoit/workspace/imobiledevice/binary/win/lib/pkgconfig" LD=i586-mingw32msvc-ld CC="/opt/compiler/llvm31/bin/clang -target i386-pc-mingw32 -isysroot=/opt/compiler/win" CXX="$CC -ccc-cxx" ../configure --prefix=/home/benoit/workspace/imobiledevice/binary/win/ --host=i586-mingw32msvc --enable-debug-log  --without-cython

lire la suite


_Cross compilation with clang, mingw and cmake

Intro

I will present here the toolchain to use clang and mingw to cross compile with cmake from linux.
If you are looking for the toolchain to target macosx, please read this post: cmake toolchain for cross compilation targetting MacOSX

lire la suite


_clang targetting mingw: issue with common symbol

I tried to compile libxml with my new configured clang cross compiler.

So, as for others project the “configure” command works good, but at the end of the make, when it link the dll, I receive hundreds of errors:

.libs/entities.o:(.data+0x240): multiple definition of `xmlMalloc'
.libs/SAX.o:(.data+0x8): first defined here
.libs/entities.o:(.data+0x270): multiple definition of `xmlRealloc'
.libs/SAX.o:(.data+0x10): first defined here
.libs/entities.o:(.data+0x3b4): multiple definition of `xmlFree'
.libs/SAX.o:(.data+0x14): first defined here
...

I check the compilation with the standard gcc cross compiler, and it works !
So, let’s check the difference on SAX.o between gcc build and clang build. Using, nm, you can see the symbols defined in the object file:

For clang:

$ i586-mingw32msvc-nm .libs/SAX.o | grep xmlMalloc
00000008 D _xmlMalloc

For gcc:

$ i586-mingw32msvc-nm .libs/SAX.o | grep xmlMalloc
00000010 C _xmlMalloc

The difference is explain in the nm documentation:

C
The symbol is common. Common symbols are uninitialized data. When linking, multiple common symbols may appear with the same name. If the symbol is defined anywhere, the common symbols are treated as undefined references. For more details on common symbols, see the discussion of –warn-common in Linker options.

D
The symbol is in the initialized data section.

This seems to be a problem in the ClangAS class. I will try to find where the issue comes from. As a start, here is a basic program to reproduce it.


_Debugging the C preprocessor

When I try to debug a complex project, I’m often confronted to find the value of preprocessor values and condition.

As you probably know, you can’t debug the preprocess with messages. You can use the #warning directive to print some messages, but you won’t be abble to print the value of your variables.

So the easiest way to debug the preprocessor is to view the source after that gcc / clang execute the preprocessor.
To do this, just execute the compilation with the “-E” option:

/opt/compiler/llvm31/bin/clang -target i386-pc-mingw32 -E SAX.c  > SAX_pp.c


_Cross compilation: build, host and target

Definitions

  • build: The current environment. You should never explicit it
  • host: Where the executable/library will run on
  • target: The target of the executable library you are building. This make sense only for cross compiler (you are building a compiler that produce code for target

From gcc documentation:

lire la suite