Description of problem: when cross-compiling a C++ program which uses Boost::Date_Time, mingw32-configure finds the Boost::Date_Time library but stops with the error: "Could not find a version of the library!" Version-Release number of selected component (if applicable): mingw32-boost.noarch 1.48.0-9.fc17 How reproducible: always Steps to Reproduce: 1. see attachment 2. 3. Actual results: Expected results: Additional info: [brian@cilla mingwboost]$ mingw32-configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for i686-w64-mingw32-strip... /usr/bin/i686-w64-mingw32-strip checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether i686-w64-mingw32-g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of i686-w64-mingw32-g++... gcc3 checking for boostlib >= 1.20.0... yes checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc checking whether we are using the GNU C compiler... yes checking whether i686-w64-mingw32-gcc accepts -g... yes checking for i686-w64-mingw32-gcc option to accept ISO C89... none needed checking dependency style of i686-w64-mingw32-gcc... gcc3 checking whether the Boost::Date_Time library is available... yes configure: error: Could not find a version of the library!
Could you please re-upload the attachment? It looks like the initial attachment upload went wrong. Could you also please upload the config.log file (which gets created when you run mingw32-configure) ?
Created attachment 643661 [details] config.log
Created attachment 643772 [details] Makefile.am
Created attachment 643773 [details] configure.ac
Created attachment 643774 [details] mingwboost.cpp
I've reattached all the files needed to recreate the bug. [brian@cilla tmp]$ ls configure.ac Makefile.am mingwboost.cpp [brian@cilla tmp]$ then run the following... mkdir m4 autoreconf -vfi mingw32-configure gives the output above... running just "./configure;make" gives a linux executable which works... thanks
When running mingw32-configure I get the following error: ./configure: line 3008: AX_BOOST_BASE: command not found ./configure: line 3009: AX_BOOST_DATE_TIME: command not found Did you use a special autoconf macro file to detect boost?
I just google'd a bit and I stumbled across https://github.com/tsuna/boost.m4 With this autoconf macro I was able to detect the MinGW boost package properly. Also see http://stackoverflow.com/questions/2386161/why-autoconf-isnt-detecting-boost-properly
I was using the macro provided with Fedora (autoconf-archive.noarch) [root@cilla ~]# rpm -ql autoconf-archive.noarch | grep boost /usr/share/aclocal/ax_boost_asio.m4 /usr/share/aclocal/ax_boost_base.m4 /usr/share/aclocal/ax_boost_chrono.m4 /usr/share/aclocal/ax_boost_date_time.m4 /usr/share/aclocal/ax_boost_filesystem.m4 /usr/share/aclocal/ax_boost_iostreams.m4 /usr/share/aclocal/ax_boost_locale.m4 /usr/share/aclocal/ax_boost_program_options.m4 /usr/share/aclocal/ax_boost_python.m4 /usr/share/aclocal/ax_boost_regex.m4 /usr/share/aclocal/ax_boost_serialization.m4 /usr/share/aclocal/ax_boost_signals.m4 /usr/share/aclocal/ax_boost_system.m4 /usr/share/aclocal/ax_boost_test_exec_monitor.m4 /usr/share/aclocal/ax_boost_thread.m4 /usr/share/aclocal/ax_boost_unit_test_framework.m4 /usr/share/aclocal/ax_boost_wave.m4 /usr/share/aclocal/ax_boost_wserialization.m4 using the alternative boost.m4 macro, I can get the example program to compile. (but, probably due to my incompetence, I cannot get the executable to run -- missing library even though I think I've added the static option.) Should I move this bug to the autoconf-archive.noarch?
(In reply to comment #9) > using the alternative boost.m4 macro, I can get the example program to > compile. (but, probably due to my incompetence, I cannot get the executable > to run -- missing library even though I think I've added the static option.) Excellent You also need to copy the boost .dll's over along with your executable to a Windows environment before you can run them. > Should I move this bug to the autoconf-archive.noarch? You could try to do so
so there's no way to get "--enable-static-boost" or "BOOST_STATIC" to work?
We do have a mingw32-boost-static package which contains the static boost library. I haven't tried to use it yet, but when you add '-static' to the LDFLAGS in your project then it 'should' work. (You may need to add other -l flags to the LDFLAGS as well, but you'll find that out soon enough)
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.