From: Kirk J. <kir...@gm...> - 2013-06-30 22:44:54
|
Dear MinGW Users, I am trying to build a third party project using MinGW. The project is distributed with configure and make files so my strategy is to use them through msys. In this post I will ask a few questions regarding inclusion of libraries. Having read the HOWTOs on the webpage I think some context is necessary so this is a somewhat longer post. Therefore I will prefix the questions with numbers. The project depends on boost, Hunspell and wxWidgets: I compiled what I believe are the two relevant boost libs, regex and system, and put them in H:\MinGW\lib. I put the entire set of boost headers in H:\MinGW\include\boost. I compiled Hunspell and put the libs in H:\MinGW\lib and the headers in H:\MinGW\include\hunspell. I compiled wxWidgets and accidentally allowed it to install in H:\MinGW\msys\1.0\local (ie exactly where it would be if msys were a real Unix system). Having done this, H:\MinGW\msys\1.0\local\lib and \include contain _only_ wxWidgets related files. In msys I navigate to the root directory of the project and do $ configure the script eventually says checking whether the Boost::Regex library is available... yes configure: error: Could not find a version fo the Boost::Regex library! This is puzzling to me but noticing that the configure script allows for specification of the boost libs I did $configure --with-boost-libdir=H:/MinGW/lib This seems to work. 1. Why do I need to specify a location that's supposed to be searched by default? In particular wxWidgets is found. 2. Is this because, working from msys somehow allows configure to find my wxWidgets files in H:\MinGW\msys\1.0\local\? I do note a line "checking for Hunspell_create in -lhunspell... no". Now when I do $make I get through all of the source files without error (this was not the case before I compiled hunspell and added the libs to H:\MinGW\lib). When the final stage of linking the .o files together is attempted there is an error: " undefined reference to 'boost::system::system_category()' " I note that there is an -lboost_regex-mt-d option in the g++ invocation. I suppose that I need to add a similar one for boost_system. 3. How is this sanely done? Finding the following line in configure.ac AC_CHECK_LIB([hunspell],[Hunspell_create]) I thought I should add a similar line: AC_CHECK_LIB([boost_system], [main]). Reading this tutorial (http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html) I see that I should next run aclocal. Doing so I get "warning: macro 'AM_OPTIONS_WXCONFIG' not found in library" "warning: macro 'AM_PATH_WXCONFIG' not found in library" which leads to related errors when I try autoconf: error: possibly undefined macro: AM_OPTIONS_WXCONFIG One option would be to track down this macro problem, but I thought I'd ask here if there's a simpler way to include the library. Thank you for your time and consideration. Regards, kjoppy |
From: John B. <joh...@ho...> - 2013-07-01 16:48:00
|
On Sun, 30 Jun 2013 15:44:46 -0700, Kirk Joppy wrote: > > Dear MinGW Users, > > I am trying to build a third party project using MinGW. The project is > distributed with configure and make files so my strategy is to use > them through msys. In this post I will ask a few questions regarding > inclusion of libraries. Having read the HOWTOs on the webpage I think > some context is necessary so this is a somewhat longer post. Therefore > I will prefix the questions with numbers. > > The project depends on boost, Hunspell and wxWidgets: > > I compiled what I believe are the two relevant boost libs, regex and > system, and put them in H:\MinGW\lib. I put the entire set of boost > headers in H:\MinGW\include\boost. > > I compiled Hunspell and put the libs in H:\MinGW\lib and the headers > in H:\MinGW\include\hunspell. > > I compiled wxWidgets and accidentally allowed it to install in > H:\MinGW\msys\1.0\local (ie exactly where it would be if msys were a > real Unix system). Having done this, H:\MinGW\msys\1.0\local\lib and > \include contain _only_ wxWidgets related files. > > In msys I navigate to the root directory of the project and do > $ configure > the script eventually says > checking whether the Boost::Regex library is available... yes > configure: error: Could not find a version fo the Boost::Regex library! > > This is puzzling to me but noticing that the configure script allows > for specification of the boost libs I did > > $configure --with-boost-libdir=H:/MinGW/lib > > This seems to work. > > 1. Why do I need to specify a location that's supposed to be searched > by default? > > In particular wxWidgets is found. I don't know. Assuming that gcc.exe is in H:\MingW\bin then H:\MinGW\lib should be searched by default. I believe that gcc will also search c:\mingw\include and c:\mingw\lib for headers and libraries, even if gcc != c:\mingw\bin\gcc.exe. Another poster suggested to you that wxWidget installs a script that tells you where to find its headers and libraries. I mentioned pkg-config (which does somthing similar for various packages) in another post to you. For example: $ pkg-config --list-all | grep -i hunspell hunspell hunspell - Hunspell spellchecking library # find out locations of hunspell headers and libraries $ pkg-config --cflags hunspell -IC:/MinGW/local/include/hunspell $ pkg-config --libs hunspell -LC:/MinGW/local/lib -lhunspell-1.3 Therefore, if you are at a MSYS prompt and you want to build myprog.c and link it to hunspell, you can type: $ gcc -o myprog.exe `pkg-config --cflags hunspell` myprog.c \ `pkg-config --libs hunspell` Pleae note the backticks ` enclosing the pkg-config commands. > > 2. Is this because, working from msys somehow allows configure to find > my wxWidgets files in H:\MinGW\msys\1.0\local\? > > I do note a line "checking for Hunspell_create in -lhunspell... no". > Assuming that wxWidgets has a script that works like pkg-config, it would have been built when wxWidgets was built, so it knows where to find wxWidgets. You will note that on my system -lhunspell will not work. I would need -lhunspell-1.3, according to pkg-config, and sure enough: $ ls /mingw/local/lib/*hunspell* -1 /mingw/local/lib/libhunspell-1.3.a /mingw/local/lib/libhunspell-1.3.dll.a /mingw/local/lib/libhunspell-1.3.la For this to work on your system, pkg-config must be present when you are building packages that know about pkg-config. Such packages will construct, for example, hunspell.pc (which contains the paths) which will be copied to the location where pkg-config looks for .pc files. Some packages provide their own scripts for this purpose, typically named as *-config. For example: /mingw/local/bin/GraphicsMagick++-config /mingw/local/bin/GraphicsMagick-config /mingw/local/bin/GraphicsMagickWand-config /mingw/local/bin/curl-config /mingw/local/bin/freetype-config The documentation for your library should tell you how to compile and link to it. I also recommend that you install pkg-config. > Now when I do > $make > I get through all of the source files without error (this was not the > case before I compiled hunspell and added the libs to H:\MinGW\lib). > When the final stage of linking the .o files together is attempted > there is an error: > " undefined reference to 'boost::system::system_category()' " > I note that there is an -lboost_regex-mt-d option in the g++ > invocation. I suppose that I need to add a similar one for > boost_system. > > 3. How is this sanely done? If a required library really is missing from the comand line, you can try using the LIBS environment variable when configuring: $LIBS=-l<library-name> ./configure where <library-name> is the missing library e.g. -lboost_regex-mt-d. > > Finding the following line in configure.ac > AC_CHECK_LIB([hunspell],[Hunspell_create]) > I thought I should add a similar line: > AC_CHECK_LIB([boost_system], [main]). > Reading this tutorial > (http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html) I > see that I should next run aclocal. Doing so I get > "warning: macro 'AM_OPTIONS_WXCONFIG' not found in library" > "warning: macro 'AM_PATH_WXCONFIG' not found in library" > which leads to related errors when I try autoconf: > error: possibly undefined macro: AM_OPTIONS_WXCONFIG The source files for wxWidgets should contain m4 macros (*.m4). These were probably installed in a place where aclocal does not search by default, so you probably have to copy them to the default location or add -I /path/to/wxWidgets/macros to your aclocal command line. > > One option would be to track down this macro problem, but I thought > I'd ask here if there's a simpler way to include the library. > > > Thank you for your time and consideration. > > Regards, > kjoppy > |
From: Eli Z. <el...@gn...> - 2013-07-01 17:14:14
|
> Date: Sun, 30 Jun 2013 15:44:46 -0700 > From: Kirk Joppy <kir...@gm...> > > The project depends on boost, Hunspell and wxWidgets: > > I compiled what I believe are the two relevant boost libs, regex and > system, and put them in H:\MinGW\lib. I hope you've put DLL files, if any, in H:\MinGW\bin, not in lib. > I put the entire set of boost headers in H:\MinGW\include\boost. Why not in H:\MinGW\include? Are programs compiled with Boost supposed to say #include <boost/foo.h> or #include <foo.h> ? In the latter case, you just made your life harder, because you will now need to configure programs so that -IH:/MinGW/include/boost switch is passed to the compiler. > In msys I navigate to the root directory of the project and do > $ configure > the script eventually says > checking whether the Boost::Regex library is available... yes > configure: error: Could not find a version fo the Boost::Regex library! > > This is puzzling to me but noticing that the configure script allows > for specification of the boost libs I did > > $configure --with-boost-libdir=H:/MinGW/lib > > This seems to work. > > 1. Why do I need to specify a location that's supposed to be searched > by default? Look in config.log for the answer, it will tell you what were the compiler error messages when it tried the failed test, without the "--with-boost-libdir=" switch. > In particular wxWidgets is found. > > 2. Is this because, working from msys somehow allows configure to find > my wxWidgets files in H:\MinGW\msys\1.0\local\? Again, the answer is within config.log. > I do note a line "checking for Hunspell_create in -lhunspell... no". Once again, look inside config.log for clues. > Now when I do > $make > I get through all of the source files without error (this was not the > case before I compiled hunspell and added the libs to H:\MinGW\lib). > When the final stage of linking the .o files together is attempted > there is an error: > " undefined reference to 'boost::system::system_category()' " > I note that there is an -lboost_regex-mt-d option in the g++ > invocation. I suppose that I need to add a similar one for > boost_system. Your configure was botched, so there's small wonder that the build fails in "interesting" ways. My advice is not to sweep the problem under the carpet, e.g. by passing non-default switches to configure. Instead, whenever there's a first sign of trouble, stop right there, look in config.log and make sure you understand the problem completely, before you decide how to work around it. At this stage of your experience and knowledge (no offense intended), I would guess that 99.9% of problems are because you misconfigured your system or installed prerequisite packages incorrectly. So kludging around such problems would be the last alternative I'd recommend. > 3. How is this sanely done? > > Finding the following line in configure.ac > AC_CHECK_LIB([hunspell],[Hunspell_create]) > I thought I should add a similar line: > AC_CHECK_LIB([boost_system], [main]). No, no, no! Do NOT go there. Just look in config.log for the error messages that failed the hunspell test, and fix whatever caused them. |
From: Kirk J. <kir...@gm...> - 2013-07-02 17:51:07
|
===First John's comments=== > Assuming that gcc.exe is in H:\MingW\bin then H:\MinGW\lib should be > searched by default. I believe that gcc > will also search c:\mingw\include > and c:\mingw\lib for headers and libraries, even if > gcc != c:\mingw\bin\gcc.exe. Looking around through the various autotools related files I found some evidence that the boost path was being explicitly set to something that only makes sense in a Unix file system, so I think this makes sense now. > Another poster suggested to you that wxWidget installs a script that > tells you where to find its headers and libraries. I mentioned > Assuming that wxWidgets has a script that works like pkg-config, it would > have been built when wxWidgets was built, so it knows where to find > wxWidgets. Yes, I believe configure is finding and using that file. This also makes some sense now. > You will note that on my system -lhunspell will not work. I would need > -lhunspell-1.3, according to pkg-config, and sure enough: Aha! I changed the name of the hunspell libs to not have the trailing 1.3 and now configure deals with hunspell without the error. Thanks. > I also recommend that you install pkg-config. For now I am trying to keep it simple but I will definitely look into this. > If a required library really is missing from the comand line, you can > try using the LIBS environment variable when configuring: > $LIBS=-l<library-name> ./configure This worked. It seems that the configure script distributed with the project simply omit this library for some reason. For example in the configure.ac file that came with the project I find AX_BOOST_REGEX but no similar macro for boost_system. I have contacted the original author. Thank you. Little directed hints like this significantly increase my ability to understand the docs for the various autotools utilities. > The source files for wxWidgets should contain m4 macros (*.m4). These > were probably installed in a place where aclocal does not search by > default, so you probably have to copy them to the default location > or add -I /path/to/wxWidgets/macros to your aclocal command line. Aha! I now see that the alocal.m4 script that came with the project already had macros for boost_regex and wxWindows inside. When I tried to run aclocal myself the wx macros weren't found for exactly the reason you say. This was very useful advice, thank you. I now understand that I need to have each package's .m4 files in place before invoking aclocal. ===Now Eli's comments=== > I hope you've put DLL files, if any, in H:\MinGW\bin, not in lib. Thanks, I had no idea you had to do that. I'm trying to do static linking though so I don't actually want dlls (but see below). > Why not in H:\MinGW\include? Are programs compiled with Boost supposed to say > #include <boost/foo.h> > or > #include <foo.h> The former. Hence I think my choice to put headers in MinGW\include\boost made sense. > Look in config.log for the answer, it will tell you what were the > compiler error messages when it tried the failed test, without the > "--with-boost-libdir=" switch. Here's what I find in the log when I don't explicitly tell configure where to find the boost libs: configure:4264: checking for boostlib >= 1.37.0 configure:4333: g++ -c -O2 conftest.cpp >&5 configure:4333: $? = 0 configure:4335: result: yes configure:4512: checking whether the Boost::Regex library is available configure:4535: g++ -c -O2 conftest.cpp >&5 configure:4535: $? = 0 configure:4549: result: yes configure:4697: error: Could not find a version of the Boost::Regex library! This does not seem to elucidate the error. ===FINALLY=== Using John's suggestion of adding the LIBS environment variable I was able to get an exe. Unfortunately when I try to launch it I get a complaint that the dlls aren't found. Clearly the system is trying to dynamically link, whereas I would like a statically linked build. Is this a job for MinGW per se or do I need to go ask the boost folks what's up? There are a bunch of posts on StackOverflow complaining about trying to statically link boost with MinGW, each containing somewhat varying information. If someone here has actually done it, please advise. Meanwhile I'll just try things. Thank you for your time. You guys are really helpful. I find this mailing list very compatible with being a newcomer willing to dig into things. Kindest regards, kjoppy |
From: Eli Z. <el...@gn...> - 2013-07-02 20:06:22
|
> Date: Tue, 2 Jul 2013 10:50:59 -0700 > From: Kirk Joppy <kir...@gm...> > > > Look in config.log for the answer, it will tell you what were the > > compiler error messages when it tried the failed test, without the > > "--with-boost-libdir=" switch. > > Here's what I find in the log when I don't explicitly tell configure > where to find the boost libs: > > configure:4264: checking for boostlib >= 1.37.0 > configure:4333: g++ -c -O2 conftest.cpp >&5 > configure:4333: $? = 0 > configure:4335: result: yes > configure:4512: checking whether the Boost::Regex library is available > configure:4535: g++ -c -O2 conftest.cpp >&5 > configure:4535: $? = 0 > configure:4549: result: yes > configure:4697: error: Could not find a version of the Boost::Regex library! > > This does not seem to elucidate the error. That cannot be the whole story, there should be "the program that failed" or some such after that. Don't give up, and don't get into the habit of hacking around problems you don't understand. |
From: John B. <joh...@ho...> - 2013-07-03 12:54:25
|
Eli Zaretskii wrote: > > [Why private mail?] USually when I hit "Reply" the message goes to the list. This time it went to you, perhaps because your message was "To:" Kirk and "CC:" mingw-users. > >> From: John Brown >> Date: Tue, 2 Jul 2013 16:25:03 -0400 >> >>>> configure:4697: error: Could not find a version of the Boost::Regex library! >>>> >>>> This does not seem to elucidate the error. >>> >>> That cannot be the whole story, there should be "the program that >>> failed" or some such after that. Don't give up, and don't get into >>> the habit of hacking around problems you don't understand. >> >> >> Certainly there "should be" a meaningful error message, but why are you >> so sure that there must be one? > > Because I know how configure scripts work and what they write to > config.log. It's not up top the programmer to decide, any error in > running a test program shows the failed program's source. It is too much work for me to find an example now, but I am sure that I have seen error messages in config.log that did not explain why the test failed, and I had to find out by performing the test myself. It could have been a package that had a custom (i.e. not generated by autoconf) configure script, so I will take your word for it that a programmer cannot suppress compiler error messages in config.log. Regards, John Brown. |
From: Eli Z. <el...@gn...> - 2013-07-03 13:36:29
|
> From: John Brown <joh...@ho...> > Date: Wed, 3 Jul 2013 08:54:16 -0400 > > >> Certainly there "should be" a meaningful error message, but why are you > >> so sure that there must be one? > > > > Because I know how configure scripts work and what they write to > > config.log. It's not up top the programmer to decide, any error in > > running a test program shows the failed program's source. > > It is too much work for me to find an example now, but I am sure that I > have seen error messages in config.log that did not explain why the test > failed, and I had to find out by performing the test myself. It could > have been a package that had a custom (i.e. not generated by autoconf) > configure script, so I will take your word for it that a programmer cannot > suppress compiler error messages in config.log. Unless the programmer stupidly writes a configure script herself, instead of using Autoconf macros, the failed program's source will always be present in config.log, AFAIK. |
From: Kirk J. <kir...@gm...> - 2013-07-03 16:45:23
|
> Unless the programmer stupidly writes a configure script herself, > instead of using Autoconf macros, the failed program's source will > always be present in config.log, AFAIK. Here is a copy/paste from config.log configure:4264: checking for boostlib >= 1.37.0 configure:4333: g++ -c -O2 conftest.cpp >&5 configure:4333: $? = 0 configure:4335: result: yes configure:4512: checking whether the Boost::Regex library is available configure:4535: g++ -c -O2 conftest.cpp >&5 configure:4535: $? = 0 configure:4549: result: yes configure:4697: error: Could not find a version of the Boost::Regex library! ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_c_compiler_gnu=yes ac_cv_cxx_compiler_gnu=yes ac_cv_env_CCC_set= ..and so on... ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='${SHELL} /g/Magic-Set-Editor-Source/missing --run aclocal-1.11' AMDEPBACKSLASH='\' AMDEP_FALSE='#' AMDEP_TRUE='' AMTAR='${SHELL} /g/Magic-Set-Editor-Source/missing --run tar' AUTOCONF='${SHELL} /g/Magic-Set-Editor-Source/missing --run autoconf' AUTOHEADER='${SHELL} /g/Magic-Set-Editor-Source/missing --run autoheader' AUTOMAKE='${SHELL} /g/Magic-Set-Editor-Source/missing --run automake-1.11' AWK='gawk' BOOST_CPPFLAGS='' BOOST_LDFLAGS='' BOOST_REGEX_LIB='' ...and so on... ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "magicseteditor" #define PACKAGE_TARNAME "magicseteditor" #define PACKAGE_VERSION "0.3.9" #define PACKAGE_STRING "magicseteditor 0.3.9" #define PACKAGE_BUGREPORT "tw...@us..." #define PACKAGE_URL "" #define PACKAGE "magicseteditor" #define VERSION "0.3.9" #define HAVE_BOOST /**/ #define HAVE_BOOST_REGEX /**/ configure: exit 1 |
From: Kirk J. <kir...@gm...> - 2013-07-03 17:59:32
|
Still trying to figure out the most sane way to get my build system running. I think I'm starting to understand the significant issues so I'd like to break it down and see if you guys think I'm on the right track. I believe the root of my confusion is in the division between MinGW and msys. I want to be able to use a third party project's autotools build system. I think this means that I need to use msys because I need to run configure and make. Since these various autotools components will live inside the msys file system it seems that I have no choice but to install my external packages into the msys file system like so $ cd PACKAGE_ROOT $ ./configure --prefix=/MSYS_ROOT/ $ make $ make install This necessarily means MinGW won't find the dependencies by default when I try to build the project. However, running configure should set up compiler flags to ensure that gcc finds the headers and libs. This means that putting all the packages in the msys file system should actually work. Is this actually a good idea? I did this with wxWidgets and it does appear to work without any additional issues. I note that the MinGW webpage says that packages should be installed like this: ./configure --prefix=/mingw make make install and offers the following advice: "Installing to "/usr/local" should be avoided, since the MinGW compiler won't look there by default." This contradicts my self-derived conclusions above. I understand that installing to /mingw will allow external libs and headers to be automatically found by the compiler, but it seems that this would make using my package's configure script needlessly complicated. Some dependencies may not be configurable with autotools through msys (I'm looking at you, boost). For those packages I assume I should just obtain the libs and put them somewhere that autotools will find. In essence I am coming to the conclusion that autotools dictates where I install dependencies. This seems wrong so I thought I should post here and get feedback. Thank you for your time. regards, kjoppy |
From: Sergio N. <sfh...@ho...> - 2013-07-03 18:44:23
|
> Still trying to figure out the most sane way to get my build system > running. I think I'm starting to understand the significant issues so > I'd like to break it down and see if you guys think I'm on the right > track. Since last week .... it's taking time! This is what I get when I type: ./configure --prefix=/mingw checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /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... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether /mingw/bin/g++.exe accepts -g... yes checking for style of include used by make... GNU checking dependency style of /mingw/bin/g++.exe... gcc3 checking for gcc... /mingw/bin/gcc.exe checking whether we are using the GNU C compiler... yes checking whether /mingw/bin/gcc.exe accepts -g... yes checking for /mingw/bin/gcc.exe option to accept ISO C89... none needed checking dependency style of /mingw/bin/gcc.exe... gcc3 checking for Hunspell_create in -lhunspell... yes checking for boostlib >= 1.37.0... yes checking whether the Boost::Regex library is available... yes checking for main in -lboost_regex... yes checking for wx-config... /mingw/bin/wx-config checking for wxWidgets version >= 2.8.0... yes (version 2.8.12) checking for wxWidgets static library... yes checking how to run the C preprocessor... /mingw/bin/gcc.exe -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for size_t... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for ANSI C header files... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking sys/select.h usability... no checking sys/select.h presence... no checking for sys/select.h... no checking sys/socket.h usability... no checking sys/socket.h presence... no checking for sys/socket.h... no checking types of arguments for select... int,int *,struct timeval * checking for floor... yes checking for memset... yes checking for pow... yes checking for select... no checking for sqrt... yes checking whether the compiler provides atomic builtins... yes configure: creating ./config.status config.status: creating Makefile config.status: creating src/config.h config.status: executing depfiles commands Hope it helps. Ser. |
From: Eli Z. <el...@gn...> - 2013-07-03 18:48:45
|
> Date: Wed, 3 Jul 2013 09:45:13 -0700 > From: Kirk Joppy <kir...@gm...> > > configure:4264: checking for boostlib >= 1.37.0 > configure:4333: g++ -c -O2 conftest.cpp >&5 > configure:4333: $? = 0 > configure:4335: result: yes > configure:4512: checking whether the Boost::Regex library is available > configure:4535: g++ -c -O2 conftest.cpp >&5 > configure:4535: $? = 0 > configure:4549: result: yes > configure:4697: error: Could not find a version of the Boost::Regex library! Then look inside configure itself, where this string appears: checking whether the Boost::Regex library is available (should be around line 4512 in the script), and you will see the test program it tried to compile and the compiler command it used to do so. |
From: John B. <joh...@ho...> - 2013-07-03 20:51:33
|
On Wed, 3 Jul 2013 21:48:28 +0300, Eli Zaretskii wrote: >> From: Kirk Joppy >> >> configure:4264: checking for boostlib>= 1.37.0 >> configure:4333: g++ -c -O2 conftest.cpp>&5 >> configure:4333: $? = 0 >> configure:4335: result: yes >> configure:4512: checking whether the Boost::Regex library is available >> configure:4535: g++ -c -O2 conftest.cpp>&5 >> configure:4535: $? = 0 >> configure:4549: result: yes >> configure:4697: error: Could not find a version of the Boost::Regex library! > > Then look inside configure itself, where this string appears: > > checking whether the Boost::Regex library is available > > (should be around line 4512 in the script), and you will see the test > program it tried to compile and the compiler command it used to do so. > I knew that I have had to do this. I just couldn't prove it. Regards, John Brown. |
From: Eli Z. <el...@gn...> - 2013-07-03 19:15:50
|
> Date: Wed, 3 Jul 2013 10:59:26 -0700 > From: Kirk Joppy <kir...@gm...> > > I believe the root of my confusion is in the division between MinGW and msys. There is no division, actually. It's an illusion. Any tool you use in the build process can be either MinGW or MSYS, with the following 2 exceptions: . the shell must be from MSYS . the compiler and its subprograms must be from MinGW Everything else can be from anywhere, but for best results it is advisable to use MSYS tools where possible. E.g., in my builds I use MSYS tools, except pkg-config and makeinfo, which are MinGW programs. > I want to be able to use a third party project's autotools build > system. What does that include, specifically? There's no way to answer your questions without some details about what hides behind "third party project's autotools build system". Please elaborate. > I think this means that I need to use msys because I need to > run configure and make. To run configure and the Makefiles it produced, yes, you need MSYS. > Since these various autotools components will > live inside the msys file system it seems that I have no choice but to > install my external packages into the msys file system like so Again, this depends on what you mean by "autotools components" and whether "external packages" are the same as "autotools components" or include additional tools, and if the latter, which ones? > $ cd PACKAGE_ROOT > $ ./configure --prefix=/MSYS_ROOT/ > $ make > $ make install > > This necessarily means MinGW won't find the dependencies by default > when I try to build the project. If by "dependencies" you mean packages needed by the MinGW compiler and linker to compile and link your program, then no, these dependencies should not be installed from MSYS root, but from the MinGW root. > However, running configure should set up compiler flags to ensure > that gcc finds the headers and libs. That doesn't happen by magic. The configure script looks for headers and libraries where the compiler and the linker look for them -- simply because the configure script invokes the compiler and the linker to find out whether a header file or a library are available, and if the compiler/linker succeed, the script decides that the header/library is available. As a variation on this, when a dependency installs a .pc file and the configure script uses pkg-config to tell where to look for the package's headers and libraries are, then you could have the headers and libraries in some non-default (as far as MinGW GCC is concerned) place, provided that you configure pkg-config to look for the *.pc files where you have them installed. But not every configure script uses pkg-config for every feature it probes, and some don't use pkg-config at all. > This means that putting all the packages in the msys file system > should actually work. It might work sometimes, but will most probably break more than once, depending on the configury of the package you are trying to build. By contrast, installing from the MinGW root will work in a lot more situations and packages. > "Installing to "/usr/local" should be avoided, since the MinGW > compiler won't look there by default." > > This contradicts my self-derived conclusions above. I understand that > installing to /mingw will allow external libs and headers to be > automatically found by the compiler, but it seems that this would make > using my package's configure script needlessly complicated. Again, the compiler cannot "automatically" find header files and libraries, unless they are in the directories it searches by default. Otherwise, it needs help in the form of the -I and -L switches. If pkg-config is used by configure, then the corresponding *.pc files supply the necessary compiler and linker switches, but that's all the magic there is. > In essence I am coming to the conclusion that autotools dictates where > I install dependencies. This seems wrong so I thought I should post > here and get feedback. My advice is to install in the default places. You will save you a lot of grief that way. |
From: Cesar S. <ces...@gm...> - 2013-07-04 00:01:19
|
On 07/03/2013 02:59 PM, Kirk Joppy wrote: > Since these various autotools components will > live inside the msys file system it seems that I have no choice but to > install my external packages into the msys file system like so This is incorrect. The autotools are compiled with --prefix=/mingw and installed in the mingw tree. So they will have no trouble finding m4 macros placed in the mingw tree. Regards, Cesar |
From: Kirk J. <kir...@gm...> - 2013-07-04 15:07:53
|
Well it certainly appears you've got hunspell, boost, and wxWidgets properly set up. If you could list exactly what you did to install those packages it would be quite helpful. This is particularly the case with boost. |
From: Sergio N. <sfh...@ho...> - 2013-07-04 18:16:00
|
> Well it certainly appears you've got hunspell, boost, and wxWidgets > properly set up. If you could list exactly what you did to install > those packages it would be quite helpful. This is particularly the > case with boost. I've built the latest version of Hunspell, Boost and wxWidgets and they're installed in the default location (i.e --prefix=/mingw). What I did to build & install them was: ./configure --prefix=/mingw make all make install This is the last email I'm sending to this list regarding this issue/thread. Subsequent emails will be off the list. Cheers. Sergio. |
From: Kirk J. <kir...@gm...> - 2013-07-04 15:15:52
|
>> Since these various autotools components will >> live inside the msys file system it seems that I have no choice but to >> install my external packages into the msys file system like so > This is incorrect. The autotools are compiled with --prefix=/mingw and > installed in the mingw tree. So they will have no trouble finding m4 > macros placed in the mingw tree. Aha! I feel kind of stupid for not just checking that but now I see that the executables are in mingw\bin. Thanks. |
From: Kirk J. <kir...@gm...> - 2013-07-06 06:33:56
|
Understanding quite a bit more than when I started I decided to nuke my MinGW system and start over. I have a problem getting the project's configure script to find boost_regex and hunspell. If I invoke configure like this $ configure the script does not find regex. I posted about this before and stated that config.log contained no useful information. I have attached the file as config.log_regex in case anyone wants to inspect it. If I invoke configure like this $ configure --with-boost-libdir=G:/MinGW/lib the script completes without fatal errors. However, I note the following line "checking for Hunspell_create in -lhunspell... no:" We also already talked about this but as Eli suggested I should nail things down one at a time. Looking at config.log in this case I see that the system is looking for files in the directory I used to build hunspell!! I have no idea why this is happening, so I attach the config log as config.log_hunspell. I also attach an exact transcript of everything I typed into the computer since I nuked and re-installed MinGW, as "notes". The only thing that has crossed my mind is that when I built hunspell I invoked configure from /hunspell-1.3.2/msys-build as $../configure --prefix=/mingw Should I have done this from hunspell-1.3.2/src? What is the standard way to invoke configure? I realize this is a googleable question, and I've done that, but I would like to hear your thoughts on this. How does one identify the correct way to invoke autotools in this situation? Thank you for your time and ongoing assistance. Kind regards, kjoppy |
From: Eli Z. <el...@gn...> - 2013-07-06 07:20:09
|
> Date: Fri, 5 Jul 2013 23:33:47 -0700 > From: Kirk Joppy <kir...@gm...> > > If I invoke configure like this > $ configure > the script does not find regex. I posted about this before and stated > that config.log contained no useful information. I have attached the > file as config.log_regex in case anyone wants to inspect it. The only relevant part is this: configure:4264: checking for boostlib >= 1.37.0 configure:4333: g++ -c -O2 conftest.cpp >&5 configure:4333: $? = 0 configure:4335: result: yes configure:4512: checking whether the Boost::Regex library is available configure:4535: g++ -c -O2 conftest.cpp >&5 configure:4535: $? = 0 configure:4549: result: yes configure:4697: error: Could not find a version of the Boost::Regex library! I suggested to look at the relevant portion of the configure script (line numbers are shown above), and see what is it doing between lines 4549 and 4697. This should give you a clue about why it fails to "find a version of Boost::Regex library", whatever that is. > If I invoke configure like this > $ configure --with-boost-libdir=G:/MinGW/lib > the script completes without fatal errors. However, I note the following line > "checking for Hunspell_create in -lhunspell... no:" > We also already talked about this but as Eli suggested I should nail > things down one at a time. Yes. And in this case config.log tells the whole story, see below. > Looking at config.log in this case I see that the system is looking > for files in the directory I used to build hunspell!! No, it doesn't. Whatever gave you that idea? If you mean these: g:\hunspell-1.3.2\msys-build\src\hunspell/../../../src/hunspell/hunspell.cxx:25: undefined reference to `operator new(unsigned int)' then this is just the linker helpfully showing you the full absolute file names of the source files that were compiled into the Hunspell library. > I have no idea why this is happening, so I attach the config log as > config.log_hunspell. This is the clue: configure:4168: checking for Hunspell_create in -lhunspell configure:4193: gcc -o conftest.exe -g -O2 conftest.c -lhunspell >&5 g:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../libhunspell.a(hunspell.o): In function `ZN8HunspellC2EPKcS1_S1_': g:\hunspell-1.3.2\msys-build\src\hunspell/../../../src/hunspell/hunspell.cxx:25: undefined reference to `operator new(unsigned int)' All the undefined references are to C++ functions. The problem here is that the test program is compiled as a C program, while Hunspell is a C++ library, and therefore needs to be compiled with g++, not with gcc. I think this is a bug in the configure script. Or maybe the configure script relies on some specific distribution of Hunspell which provides an interface for C programs, I don't know. |
From: Nathan R. <zer...@ho...> - 2013-07-06 21:37:16
|
> Using John's suggestion of adding the LIBS environment variable I was > able to get an exe. Unfortunately when I try to launch it I get a > complaint that the dlls aren't found. Clearly the system is trying to > dynamically link, whereas I would like a statically linked build. Is > this a job for MinGW per se or do I need to go ask the boost folks > what's up? There are a bunch of posts on StackOverflow complaining > about trying to statically link boost with MinGW, each containing > somewhat varying information. If someone here has actually done it, > please advise. I accomplish this by using the "link=static" option on the b2 command line when I build boost. This way, dynamic libraries aren't built at all, and all clients of boost will link it statically. Regards, Nate |
From: Kirk J. <kir...@gm...> - 2013-07-06 22:51:56
|
> I accomplish this by using the "link=static" option on the b2 command > line when I build boost. This way, dynamic libraries aren't built at > all, and all clients of boost will link it statically. Yeah, that does definitely work. I recently read that there is a default order in which the system looks for libraries. Apparently shared libs come first. Do you understand the difference between the link and the runtime-link options in b2? I've never heard of a program statically linking to a runtime library, but is that what this option is about? |
From: Nathan R. <zer...@ho...> - 2013-07-06 23:38:21
|
> Do you understand the difference between the link and the runtime-link > options in b2? I've never heard of a program statically linking to a > runtime library, but is that what this option is about? 'link' determines whether boost is built as static or dynamic libraries. 'runtime-link' has to do with how programs that use boost link to the C++ runtime and standard libraries. With gcc (and probably with other compilers), by default the C++ runtime library (libgcc) and the C++ standard library (libstdc++) are linked dynamically. However, you can use the -static-libgcc and -static-libstdc++ options to get gcc to link them statically. This is useful if you are compiling a program with a version of gcc (and thus libstdc++) that's newer than what is (easily) available on the machines on which it will run. My understanding is that you need to set the 'runtime-link' flag to match how your program will link the runtime and standard libraries. I don't have a good understanding of why this is the case, i.e. how a boost library that's built with 'runtime-link=static' is actually different from one built with 'runtime-link=dynamic' - perhaps someone else can enlighten us on this point. Regards, Nate |
From: Kirk J. <kir...@gm...> - 2013-07-08 01:37:29
|
> This is the clue: > configure:4168: checking for Hunspell_create in -lhunspell > configure:4193: gcc -o conftest.exe -g -O2 conftest.c -lhunspell >&5 > g:/mingw/bin/../lib/gcc/ > mingw32/4.7.2/../../../libhunspell.a(hunspell.o): In function > `ZN8HunspellC2EPKcS1_S1_': > g:\hunspell-1.3.2\msys-build\src\hunspell/../../../src/hunspell > /hunspell.cxx:25: undefined reference to `operator new(unsigned int)' > All the undefined references are to C++ functions. How the heck do you know that? Is it something to do with the wacky names? > The problem here is that the test program is compiled as a C program, > while Hunspell is a C++ library, and therefore needs to be compiled > with g++, not with gcc. What is the difference? I thought gcc was a compiler driver that invokes whichever compiler is appropriate. So let's see... how does it choose the compiler... by file extension? Aha! Thanks. |
From: Eli Z. <el...@gn...> - 2013-07-08 02:41:40
|
> Date: Sun, 7 Jul 2013 18:37:21 -0700 > From: Kirk Joppy <kir...@gm...> > > > This is the clue: > > > configure:4168: checking for Hunspell_create in -lhunspell > > configure:4193: gcc -o conftest.exe -g -O2 conftest.c -lhunspell >&5 > > g:/mingw/bin/../lib/gcc/ > > mingw32/4.7.2/../../../libhunspell.a(hunspell.o): In function > > `ZN8HunspellC2EPKcS1_S1_': > > g:\hunspell-1.3.2\msys-build\src\hunspell/../../../src/hunspell > > /hunspell.cxx:25: undefined reference to `operator new(unsigned int)' > > > All the undefined references are to C++ functions. > > How the heck do you know that? Is it something to do with the wacky names? Because 'new', 'new[]', 'delete' and 'delete[]' are C++ features. Also, the file names that have *.cxx extensions hint on that, as does '__gxx_personality_v0'. > > The problem here is that the test program is compiled as a C program, > > while Hunspell is a C++ library, and therefore needs to be compiled > > with g++, not with gcc. > > What is the difference? I thought gcc was a compiler driver that > invokes whichever compiler is appropriate. So let's see... how does it > choose the compiler... by file extension? Aha! Thanks. Exactly. If conftset.c were conftest.cpp, it would have worked. |
From: Kirk J. <kir...@gm...> - 2013-07-08 05:49:26
|
> Exactly. If conftset.c were conftest.cpp, it would have worked. I suppose this means I need to learn how to generate a new configure script? I don't fully understand what determines the form of the test programs that configure uses. I see configure.ac and I have some understanding of how that controls generation of configure. I'll figure it out in time. Thanks for your help. For what it's worth I'm also investigating CMake as I'm told it's a lot more friendly than so called "autohell". |