boost builds dll's on mingw, can't use

[Imran Akbar]

Hi,
I've been having problems linking to boost using mingw. I installed
boost linking to mingw, but it installed the necessary boost-mgw files with
either .dll or .lib extensions, which mingw can't use! I tried renaming the
.lib's to .a's and the .dll's to .so's, which didn't work. then I tried
adding a 'lib' prefix to each .a or .so, which still didn't work... there
isn't actually a boost_thread library file, it's got some version number at
the end - would that be a problem? Did I install it correctly? I'm linking
to it using -lboost_thread in mingw (gcc).

Any help much appreciated.

Thanks,
Imran

[Merrill Cornish]

Imran,

I've using Boost 1.33.0 with the latest MinGW on Windows XP, and it works fine.

Could you be a bit more specific as to why MinGW "can't use" the Boost libraries?
Do you mean that references are left unresolved?

Here is an excerpt from the part of my my Makefile that deals with libraries:

BOOSTLIBS = -L${boost_libs} \
-llibboost_date_time${boost_suffix} \
-llibboost_filesystem${boost_suffix} \
-llibboost_regex${boost_suffix} \
-llibboost_serialization${boost_suffix} \
-llibboost_thread${boost_suffix} \
-llibboost_program_options${boost_suffix}

where ${boost_libs} expands into the pathname of the directory the Boost
libraries are in and ${boost_suffix} expands into "-mgw-mt-sd-1_33", which
says the libraries are compiled for MinGW, multi-threaded, static, debug, and
Boost version 1.33.

I put ${BOOSTLIBS} as the LAST thing on the call to g++ to link my .exe
file. Notice that the positioning is important.

The linker reads the files listed on the command line from left to right.
When it comes to a library file, it resolves whatever outstanding references
to that library it has AT THAT POINT in the scan. If it sees another reference
to that library later in the left to right scan after seeing the library, that later
reference goes unresolved.

The linker needs to see ALL references to library functions BEFORE it
sees the libraries themselves. So, put the libraries last.

The Boost library build process creates the libraries both with the Boost
version suffix ("1_33" in my case) and without. You can use either one as
they are identical files.

The idea is that if you use the library file versions WITHOUT the version
number suffix, then you won't have to change your Makefile when a new
version comes out. On the other hand, if you want to explicitly tie your
program to one and only one version of the Boost libraries, you can use the
filename WITH the version numbers.

Merrill

[Imran Akbar]

Thanks Merrill,
i'm actually using scons, not make... and I didn't code that part, so
I'll have to look at it. Is the problem not the extensions (.dll/.lib vs
.so/.a)? Why didn't boost name them properly when I specified mingw?

Thanks,
Imran

Post by Merrill Cornish
Imran,
I've using Boost 1.33.0 with the latest MinGW on Windows XP, and it works fine.
Could you be a bit more specific as to why MinGW "can't use" the Boost libraries?
Do you mean that references are left unresolved?
BOOSTLIBS = -L${boost_libs} \
-llibboost_date_time${boost_suffix} \
-llibboost_filesystem${boost_suffix} \
-llibboost_regex${boost_suffix} \
-llibboost_serialization${boost_suffix} \
-llibboost_thread${boost_suffix} \
-llibboost_program_options${boost_suffix}
where ${boost_libs} expands into the pathname of the directory the Boost
libraries are in and ${boost_suffix} expands into "-mgw-mt-sd-1_33", which
says the libraries are compiled for MinGW, multi-threaded, static, debug, and
Boost version 1.33.
I put ${BOOSTLIBS} as the LAST thing on the call to g++ to link my .exe
file. Notice that the positioning is important.
The linker reads the files listed on the command line from left to right.
When it comes to a library file, it resolves whatever outstanding references
to that library it has AT THAT POINT in the scan. If it sees another reference
to that library later in the left to right scan after seeing the library, that later
reference goes unresolved.
The linker needs to see ALL references to library functions BEFORE it
sees the libraries themselves. So, put the libraries last.
The Boost library build process creates the libraries both with the Boost
version suffix ("1_33" in my case) and without. You can use either one as
they are identical files.
The idea is that if you use the library file versions WITHOUT the version
number suffix, then you won't have to change your Makefile when a new
version comes out. On the other hand, if you want to explicitly tie your
program to one and only one version of the Boost libraries, you can use the
filename WITH the version numbers.
Merrill
_______________________________________________
Boost-users mailing list
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Merrill Cornish]

Imran,

Is the problem not the extensions (.dll/.lib vs .so/.a)?
Why didn't boost name them properly when I specified mingw?

.dll is for shared libraries on Windows. .lib is for static libraries on Windows.
.so and .a are for shared/static on Unix/Linux.

It shouldn't matter whether you are using GNU make or not. MinGW uses
g++ to do the linking, and it's g++ that has the file ordering requirement
on the command line.

On the other hand, if you aren't using g++ (or gcc, which calls g++), then
maybe your linker doesn't have the ordering problem.

Is the error you are getting about unresolved references?

Merrill

[Imran Akbar]

Thanks Merrill,
The error i'm getting is:

.....mingw32\bin\ld.exe: cannot find -lboost_thread

I am using gcc, but I'm not sure I understand your response - does it matter
what the prefix is and if there's a lib prefix? Was I right in changing
those to match the unix style?

Thanks,
Imran

Post by Merrill Cornish
Imran,

Is the problem not the extensions (.dll/.lib vs .so/.a)?
Why didn't boost name them properly when I specified mingw?

.dll is for shared libraries on Windows. .lib is for static libraries on Windows.
.so and .a are for shared/static on Unix/Linux.
It shouldn't matter whether you are using GNU make or not. MinGW uses
g++ to do the linking, and it's g++ that has the file ordering requirement
on the command line.
On the other hand, if you aren't using g++ (or gcc, which calls g++), then
maybe your linker doesn't have the ordering problem.
Is the error you are getting about unresolved references?
Merrill
_______________________________________________
Boost-users mailing list
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Merrill Cornish]

Imran,

Post by Imran Akbar
.....mingw32\bin\ld.exe: cannot find -lboost_thread

OK, I see two problems here.

First, are you calling ld.exe directly to link your executable,
or are you calling either gcc or g++? I initially made the mistake
of calling ld.exe directly, but found the linker couldn't even find
the C++ functions in std namespace. I was told to use gcc or
g++ because they know to automatically include the standard
runtime libraries.

Second, -lboost_thread would work only if you have a -L<directory>
where <directory> is where the Boost libraries are AND the Boost
library file was named "libboost_thread.dll" or "libboost_thread.lib".
That is, the -l option only takes care of the "lib" prefix and the
".dll" or ".lib" file extension, depending on whether you are linking
to shared or static libraries.

When Boost builds its libraries, it add a suffix to the library name
that records the major build options (which compiler, static? debug?
multi-thread? etc.). So, I'm betting that in your Boost library
directory you do NOT have a file named libboost_thread.dll
or libboost_thread.lib.

You need to include that filename suffix (and I'm talking about the
filename and not the file extension) in the argument to the -l option.

What is the full filename of the boost_thread library in the Boost
libs directory?

Merrill