Cross-compiling gflags on Linux using mingw-win32

[Islam Ossama]

Hello everyone,

I was wondering if anyone has experience cross-compling gflags. Specifically, I'm trying to cross-compile it on Linux (Ubuntu 12.04) for a Win32 target using i586-mingw32msvc-cc.I managed to compile the library itself, but when I tried to link to it I got the following errors:

i586-mingw32msvc-g++ -L"my_library_folder" -o "output_file_name" a_list_of_object_files.o -lgflags-win32

./src/honest.o:honest.cpp:(.text+0x52bc): undefined reference to `google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)'

./src/honest.o:honest.cpp:(.text+0x5338): undefined reference to `google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)'

./src/honest.o:honest.cpp:(.text+0x536d): undefined reference to `google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)'

./src/honest.o:honest.cpp:(.text+0x5398): undefined reference to `google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)'

./src/honest.o:honest.cpp:(.text+0x53c3): undefined reference to `google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)'

./src/honest.o:honest.cpp:(.text+0x53ee): more undefined references to `google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)' follow

./src/honest.o:honest.cpp:(.text+0x78b0): undefined reference to `google::ParseCommandLineFlags(int*, char***, bool)'

collect2: ld returned 1 exit status

Note: I renamed the cross-compiled library file to libgflags-win32.a so it can live in the same folder with the Linux version of the library, inside my_library_folder.

Here are the steps I used to cross-compile the gflags library:

1. ./configure CC=i586-mingw32msvc-cc --prefix=some_local_directory
   
2. That gave me a compile error when I invoked make:
   src/mutex.h:152:3: error: #error Need to implement mutex.h for your architecture, or #define NO_THREADS
3. I added the NO_THREADS flag to configure to fix that (I don't really mind using the no threads variant):
   ./configure CC=i586-mingw32msvc-cc --prefix=some_local_directory CPPFLAGS=-DNO_THREADS
   
4. That got the library to build. After "make && make install" was done, I copied libflags.a to my_library_folder and tried to build my project. That got me the error above.

The same code links correctly when compiled with native g++ against the native-compiled version of the library.

Any tips would be highly appreciated :)

Thanks!

[Islam Ossama]

It seems the problem could be related to library file format, which somewhat baffles me since everything is done using the same (cross-)compiler!

Is anyone aware of some library file format specifications in the gflags config? Maybe something is forcing a different format somehow? This is a bit above me experience level so I'm kinda shooting in the dark here...

[Andreas Schuh]

Hi Islam,

unfortunately, I have no experience with cross-compiling code. But if you suspect the problem to be in the build configuration of gflags, would you mind trying to configure the build with CMake instead ? Some information regarding cross-compilation and CMake can be found at http://www.cmake.org/Wiki/CMake_Cross_Compiling. The CMake migration branch of gflags is already mature and I actually would have liked to make it the new master/release weeks ago...

Andreas

[Islam El-Nabarawy]

Hello Andreas,

Thanks for the reply. I will switch to the CMake branch now and give it a try, and I will let you know how it goes.

Thanks!

Best Regards,
Islam El-Nabarawy

--
You received this message because you are subscribed to a topic in the Google Groups "google-gflags" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-gflags/nKsT1WS41Dk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-gflag...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-gflags.
For more options, visit https://groups.google.com/groups/opt_out.

[Islam El-Nabarawy]

Hello Andreas,

I believe you just saved the day; it works! I switched to the CMake migration branch and used the toolchain file and instructions from here: http://www.cmake.org/Wiki/CmakeMingw. It worked like a charm. I even re-generated my Linux libflags.a using CMake for consistency.

Thanks a lot for the help. I hope this helps anyone else who runs into the same issue :)

Best Regards,
Islam El-Nabarawy

[Andreas Schuh]

That’s great news. I am glad it worked out. Another reason to bump the priority of releasing the CMake migration branch…

On Jan 8, 2014, at 1:47 PM, Islam El-Nabarawy <islam....@gmail.com> wrote:

Hello Andreas,

I believe you just saved the day; it works! I switched to the CMake migration branch and used the toolchain file and instructions from here: http://www.cmake.org/Wiki/CmakeMingw. It worked like a charm. I even re-generated my Linux libflags.a using CMake for consistency.

Thanks a lot for the help. I hope this helps anyone else who runs into the same issue :)

Best Regards,
Islam El-Nabarawy

On Wed, Jan 8, 2014 at 2:55 PM, Islam El-Nabarawy <islam....@gmail.com> wrote:

Hello Andreas,

Thanks for the reply. I will switch to the CMake branch now and give it a try, and I will let you know how it goes.

Thanks!

Best Regards,
Islam El-Nabarawy

On Wed, Jan 8, 2014 at 2:51 PM, Andreas Schuh <andreas....@gmail.com> wrote:

Hi Islam,

unfortunately, I have no experience with cross-compiling code. But if you suspect the problem to be in the build configuration of gflags, would you mind trying to configure the build with CMake instead ? Some information regarding cross-compilation and CMake can be found at http://www.cmake.org/Wiki/CMake_Cross_Compiling. The CMake migration branch of gflags is already mature and I actually would have liked to make it the new master/release weeks ago...

Andreas

--
You received this message because you are subscribed to a topic in the Google Groups "google-gflags" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-gflags/nKsT1WS41Dk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-gflag...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-gflags.
For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups "google-gflags" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-gflag...@googlegroups.com.

[Islam El-Nabarawy]

On Wed, Jan 8, 2014 at 3:56 PM, Andreas Schuh <andreas....@gmail.com> wrote:

That’s great news. I am glad it worked out. Another reason to bump the priority of releasing the CMake migration branch…

Thanks!

Yeah, that sounds like a good idea, and it seems stable enough; I personally didn't run into any issues. What's holding it back? Anything I can help with?

Best Regards,
Islam El-Nabarawy

[Andreas Schuh]

On Wednesday, January 8, 2014 2:18:50 PM UTC, Islam Ossama wrote:

What's holding it back? Anything I can help with?

Mainly personal time allocation, I would say. At first I wanted to also get some more bug fixes (e.g., memory leaks) in a new release as well, but I think I better separate the change of the build system from any library code changes. For a complete transition to CMake, it would be great if the tests were run as separate CTest tests and further not implemented in Bash, but for example Python rather so they can be executed on Windows as well.

[Islam El-Nabarawy]

On Wed, Jan 8, 2014 at 4:57 PM, Andreas Schuh <andreas....@gmail.com> wrote:

Mainly personal time allocation, I would say. At first I wanted to also get some more bug fixes (e.g., memory leaks) in a new release as well, but I think I better separate the change of the build system from any library code changes. For a complete transition to CMake, it would be great if the tests were run as separate CTest tests and further not implemented in Bash, but for example Python rather so they can be executed on Windows as well.

 

Yeah, I know what that's like, too much to do and not enough time in the day! You might want to post an update to your Google Code page to encourage people to check out the CMake branch, though. I would have went with it from the start but I was discouraged by the text calling it "unstable" and so preferred to go with the main branch, and I imagine I'm not the first one to do that. If more people used it that might help stress-test it under different circumstances and maybe get it adopted into the main branch a bit sooner.

In all cases, it's quite a handy library! It helped me go through the whole command line parameter process in a snap, and I would definitely recommend it to other people. Hopefully if I get a chance in the near future I might fork it on Github sometime soon and see what I can do to help :)

Thanks again Andreas.

Best Regards,
Islam El-Nabarawy

[Andreas Schuh]

On Jan 13, 2014, at 7:06 PM, Islam El-Nabarawy <islam....@gmail.com> wrote:

On Wed, Jan 8, 2014 at 4:57 PM, Andreas Schuh <andreas....@gmail.com> wrote:

Mainly personal time allocation, I would say. At first I wanted to also get some more bug fixes (e.g., memory leaks) in a new release as well, but I think I better separate the change of the build system from any library code changes. For a complete transition to CMake, it would be great if the tests were run as separate CTest tests and further not implemented in Bash, but for example Python rather so they can be executed on Windows as well.

 

Yeah, I know what that's like, too much to do and not enough time in the day! You might want to post an update to your Google Code page to encourage people to check out the CMake branch, though. I would have went with it from the start but I was discouraged by the text calling it "unstable" and so preferred to go with the main branch, and I imagine I'm not the first one to do that. If more people used it that might help stress-test it under different circumstances and maybe get it adopted into the main branch a bit sooner.

Good idea. I removed the “(unstable!)” comment and added a new news of the day that the CMake branch is recommended.

In all cases, it's quite a handy library! It helped me go through the whole command line parameter process in a snap, and I would definitely recommend it to other people. Hopefully if I get a chance in the near future I might fork it on Github sometime soon and see what I can do to help :)

Thanks again Andreas.

Best Regards,
Islam El-Nabarawy

[Islam El-Nabarawy]

On Tue, Jan 14, 2014 at 2:58 AM, Andreas Schuh <andreas....@gmail.com> wrote:

Good idea. I removed the “(unstable!)” comment and added a new news of the day that the CMake branch is recommended.

Awesome!

Best Regards,
Islam El-Nabarawy