external libs with msys/autotools

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

external libs with msys/autotools

Kirk Joppy
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

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

John Brown
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
>    
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Eli Zaretskii
In reply to this post by Kirk Joppy
> Date: Sun, 30 Jun 2013 15:44:46 -0700
> From: Kirk Joppy <[hidden email]>
>
> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Kirk Joppy
===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

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Eli Zaretskii
> Date: Tue, 2 Jul 2013 10:50:59 -0700
> From: Kirk Joppy <[hidden email]>
>
> > 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.


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

John Brown
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.    
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Eli Zaretskii
> From: John Brown <[hidden email]>
> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Kirk Joppy
> 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 "[hidden email]"
#define PACKAGE_URL ""
#define PACKAGE "magicseteditor"
#define VERSION "0.3.9"
#define HAVE_BOOST /**/
#define HAVE_BOOST_REGEX /**/

configure: exit 1

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Kirk Joppy
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

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools (MagicSetEditor)

Sergio NNX
> 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.


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Eli Zaretskii
In reply to this post by Kirk Joppy
> Date: Wed, 3 Jul 2013 09:45:13 -0700
> From: Kirk Joppy <[hidden email]>
>
> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Eli Zaretskii
In reply to this post by Kirk Joppy
> Date: Wed, 3 Jul 2013 10:59:26 -0700
> From: Kirk Joppy <[hidden email]>
>
> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

John Brown
In reply to this post by Eli Zaretskii
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.    
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Cesar Strauss
In reply to this post by Kirk Joppy
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


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools (MagicSetEditor)

Kirk Joppy
In reply to this post by Sergio NNX
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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Kirk Joppy
In reply to this post by Cesar Strauss
>> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools (MagicSetEditor)

Sergio NNX
In reply to this post by Kirk Joppy
> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Kirk Joppy
In reply to this post by Kirk Joppy
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

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

config.log_regex (28K) Download Attachment
config.log_hunspell (78K) Download Attachment
notes (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Eli Zaretskii
> Date: Fri, 5 Jul 2013 23:33:47 -0700
> From: Kirk Joppy <[hidden email]>
>
> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: external libs with msys/autotools

Nathan Ridge
In reply to this post by Kirk Joppy
> 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    
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12