Specifying library locations for g++

newer
unhandled exception (assertion) in...

older
Getting a "direct" iterator from...

Scott Meyers

30 May 2007 30 May '07

5:03 a.m.

I've built Boost 1.34 for VC8 and g++ 4.1.1 on WinXP. I'm testing my installation with a simple program that uses Boost.FileSystem and Boost.Regex. Compilation is no problem, and for VC8, all I have to do to get things to link is add the location of the Boost binaries to the LIB environment variable. I was hoping that all I had to do for g++ was do the same for the LIBRARY_PATH environment variable (per http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html), but I get unresolved symbol errors during linking even after doing that. I played around with the -l option (per http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options), but nothing I tried worked. I have the following relevant binaries in my Boost binary directory: libboost_regex-mgw41-1_34.a libboost_regex-mgw41-d-1_34.a libboost_regex-mgw41-mt-1_34.a libboost_regex-mgw41-mt-d-1_34.a libboost_regex-mgw41-mt-s-1_34.a libboost_regex-mgw41-mt-sd-1_34.a libboost_regex-mgw41-s-1_34.a libboost_regex-mgw41-sd-1_34.a boost_filesystem-mgw41-1_34.a boost_filesystem-mgw41-d-1_34.a boost_filesystem-mgw41-mt-1_34.a boost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-1_34.a libboost_filesystem-mgw41-d-1_34.a libboost_filesystem-mgw41-mt-1_34.a libboost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-mt-s-1_34.a libboost_filesystem-mgw41-mt-sd-1_34.a libboost_filesystem-mgw41-s-1_34.a libboost_filesystem-mgw41-sd-1_34.a Can somebody explain or point me to an explanation of what I need to do to get a program using Boost binaries to link? I'm hoping there's something as simple as with VC8 where I can just specify a directory to look in and have the linker magically figure everything out from there. I'd like to avoid explicitly having to add a new library to link against each time I start using a new compiled Boost library in a project. Incidentally, in the above list of files, I notice that for Boost.FileSystem, there are some archives that start with lib and some that do not, while for regex, all start with lib. Is this meaningful? Thanks, Scott

Show replies by date

Bobby Ward

30 May 30 May

5:57 a.m.

To instruct g++ to look in an additional directory for libraries use "-L <path>" I believe that's what you're looking for. On 5/30/07, Scott Meyers wrote:

...

I've built Boost 1.34 for VC8 and g++ 4.1.1 on WinXP. I'm testing my installation with a simple program that uses Boost.FileSystem and Boost.Regex. Compilation is no problem, and for VC8, all I have to do to get things to link is add the location of the Boost binaries to the LIB environment variable.

I was hoping that all I had to do for g++ was do the same for the LIBRARY_PATH environment variable (per http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html), but I get unresolved symbol errors during linking even after doing that. I played around with the -l option (per http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options), but nothing I tried worked.

I have the following relevant binaries in my Boost binary directory:

libboost_regex-mgw41-1_34.a libboost_regex-mgw41-d-1_34.a libboost_regex-mgw41-mt-1_34.a libboost_regex-mgw41-mt-d-1_34.a libboost_regex-mgw41-mt-s-1_34.a libboost_regex-mgw41-mt-sd-1_34.a libboost_regex-mgw41-s-1_34.a libboost_regex-mgw41-sd-1_34.a boost_filesystem-mgw41-1_34.a boost_filesystem-mgw41-d-1_34.a boost_filesystem-mgw41-mt-1_34.a boost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-1_34.a libboost_filesystem-mgw41-d-1_34.a libboost_filesystem-mgw41-mt-1_34.a libboost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-mt-s-1_34.a libboost_filesystem-mgw41-mt-sd-1_34.a libboost_filesystem-mgw41-s-1_34.a libboost_filesystem-mgw41-sd-1_34.a

Can somebody explain or point me to an explanation of what I need to do to get a program using Boost binaries to link? I'm hoping there's something as simple as with VC8 where I can just specify a directory to look in and have the linker magically figure everything out from there. I'd like to avoid explicitly having to add a new library to link against each time I start using a new compiled Boost library in a project.

Incidentally, in the above list of files, I notice that for Boost.FileSystem, there are some archives that start with lib and some that do not, while for regex, all start with lib. Is this meaningful?

Thanks,

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com http://www.bobbyrward.com http://combustion.sourceforge.net

KSpam

6:28 a.m.

Scott,

...

I was hoping that all I had to do for g++ was do the same for the LIBRARY_PATH environment variable (per http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html), but I get unresolved symbol errors during linking even after doing that. I played around with the -l option (per http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options), but nothing I tried worked.

The -l (lowercase) option tells the linker what library to link in, and the -L (uppercase) option tells the linker where to find the library. Another potential hangup is in naming the library on the command line. Windows users are used to specifying the full name of the library, but the Unix way is to not include the "lib" prefix. The gcc compiler works the Unix way. In other words, you want "-lboost_regex" instead of "-llibboost_regex".

...

Can somebody explain or point me to an explanation of what I need to do to get a program using Boost binaries to link? I'm hoping there's something as simple as with VC8 where I can just specify a directory to look in and have the linker magically figure everything out from there. I'd like to avoid explicitly having to add a new library to link against each time I start using a new compiled Boost library in a project.

Unfortunately, the option you are looking for does not exist on the gcc compiler (to my knowledge). You want "auto_link". If you look in boost/config/auto_link.hpp, you will see a line similar to the following: #pragma comment(lib, BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib") This pragma statement is a directive that VC8 uses to automatically link in a library when a certain header is included in a compilation unit. With gcc, you have to do this task manually by adding the library name to the link line with the -l (lowercase) option. Respectfully, Justin

Vladimir Prus

6:55 a.m.

Scott Meyers wrote:

...

I've built Boost 1.34 for VC8 and g++ 4.1.1 on WinXP. I'm testing my installation with a simple program that uses Boost.FileSystem and Boost.Regex. Compilation is no problem, and for VC8, all I have to do to get things to link is add the location of the Boost binaries to the LIB environment variable.

I was hoping that all I had to do for g++ was do the same for the LIBRARY_PATH environment variable (per http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html), but I get unresolved symbol errors during linking even after doing that. I played around with the -l option (per http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options), but nothing I tried worked.

What is the exact command line you've used, and what is the exact error you've got?

...

Can somebody explain or point me to an explanation of what I need to do to get a program using Boost binaries to link? I'm hoping there's something as simple as with VC8 where I can just specify a directory to look in and have the linker magically figure everything out from there.

This is not possible. - Volodya

Scott Meyers

5:15 p.m.

Vladimir Prus wrote:

...

What is the exact command line you've used, and what is the exact error you've got?

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_filesystem -lboost_regex d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_filesystem collect2: ld returned 1 exit status Reversing the order of the libraries to link yields this: D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_regex -lboost_filesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_regex collect2: ld returned 1 exit status This suggests that whichever library is listed first is the one leading to the linker quitting. Specifying full paths doesn't help: D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lc:\boost_current\lib\boost_regex -lc:\boost_ current\lib\boost_filesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lc:\boost_current\lib\boost_regex collect2: ld returned 1 exit status But the libraries are there: D:\Temp>ls c:\boost_current\lib | grep filesystem | grep mgw boost_filesystem-mgw41-1_34.a boost_filesystem-mgw41-d-1_34.a boost_filesystem-mgw41-mt-1_34.a boost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-1_34.a libboost_filesystem-mgw41-d-1_34.a libboost_filesystem-mgw41-mt-1_34.a libboost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-mt-s-1_34.a libboost_filesystem-mgw41-mt-sd-1_34.a libboost_filesystem-mgw41-s-1_34.a libboost_filesystem-mgw41-sd-1_34.a D:\Temp>ls c:\boost_current\lib | grep regex | grep mgw libboost_regex-mgw41-1_34.a libboost_regex-mgw41-d-1_34.a libboost_regex-mgw41-mt-1_34.a libboost_regex-mgw41-mt-d-1_34.a libboost_regex-mgw41-mt-s-1_34.a libboost_regex-mgw41-mt-sd-1_34.a libboost_regex-mgw41-s-1_34.a libboost_regex-mgw41-sd-1_34.a Suggestions? Thanks, Scott

David Daeschler

5:21 p.m.

Hi Scott, I have not been following this whole thread, but unless there is a directory with the built boost libraries on your path, you need to specify the path to the boost libraries on your command line. With gcc/g++ you do this with the -L option, followed by the directory that the boost .dlls and import libraries are in. ex: -L/path/to/built/boost/libs Hope this helps. - Dave On Wed, 2007-05-30 at 10:15 -0700, Scott Meyers wrote:

...

Vladimir Prus wrote:

...
What is the exact command line you've used, and what is the exact error you've got?

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_filesystem -lboost_regex d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_filesystem collect2: ld returned 1 exit status

Reversing the order of the libraries to link yields this:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_regex -lboost_filesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_regex collect2: ld returned 1 exit status

This suggests that whichever library is listed first is the one leading to the linker quitting.

Specifying full paths doesn't help:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lc:\boost_current\lib\boost_regex -lc:\boost_ current\lib\boost_filesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lc:\boost_current\lib\boost_regex collect2: ld returned 1 exit status

But the libraries are there:

D:\Temp>ls c:\boost_current\lib | grep filesystem | grep mgw boost_filesystem-mgw41-1_34.a boost_filesystem-mgw41-d-1_34.a boost_filesystem-mgw41-mt-1_34.a boost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-1_34.a libboost_filesystem-mgw41-d-1_34.a libboost_filesystem-mgw41-mt-1_34.a libboost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-mt-s-1_34.a libboost_filesystem-mgw41-mt-sd-1_34.a libboost_filesystem-mgw41-s-1_34.a libboost_filesystem-mgw41-sd-1_34.a

D:\Temp>ls c:\boost_current\lib | grep regex | grep mgw libboost_regex-mgw41-1_34.a libboost_regex-mgw41-d-1_34.a libboost_regex-mgw41-mt-1_34.a libboost_regex-mgw41-mt-d-1_34.a libboost_regex-mgw41-mt-s-1_34.a libboost_regex-mgw41-mt-sd-1_34.a libboost_regex-mgw41-s-1_34.a libboost_regex-mgw41-sd-1_34.a

Suggestions?

Thanks,

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

David Daeschler

5:29 p.m.

After following this thread lower down, I think that you're confusing -l (lower case l) and -L (capital L). Lower case -l specifies the individual library you are linking to (ex boost_filesystem). Capital -L specifies a directory or directories (you can use -L and -l as many times as you have to) where the linker should look for the libraries specified by the lower case -l's On Wed, 2007-05-30 at 10:15 -0700, Scott Meyers wrote:

...

Vladimir Prus wrote:

...
What is the exact command line you've used, and what is the exact error you've got?

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_filesystem -lboost_regex d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_filesystem collect2: ld returned 1 exit status

Reversing the order of the libraries to link yields this:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_regex -lboost_filesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_regex collect2: ld returned 1 exit status

This suggests that whichever library is listed first is the one leading to the linker quitting.

Specifying full paths doesn't help:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lc:\boost_current\lib\boost_regex -lc:\boost_ current\lib\boost_filesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lc:\boost_current\lib\boost_regex collect2: ld returned 1 exit status

But the libraries are there:

D:\Temp>ls c:\boost_current\lib | grep filesystem | grep mgw boost_filesystem-mgw41-1_34.a boost_filesystem-mgw41-d-1_34.a boost_filesystem-mgw41-mt-1_34.a boost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-1_34.a libboost_filesystem-mgw41-d-1_34.a libboost_filesystem-mgw41-mt-1_34.a libboost_filesystem-mgw41-mt-d-1_34.a libboost_filesystem-mgw41-mt-s-1_34.a libboost_filesystem-mgw41-mt-sd-1_34.a libboost_filesystem-mgw41-s-1_34.a libboost_filesystem-mgw41-sd-1_34.a

D:\Temp>ls c:\boost_current\lib | grep regex | grep mgw libboost_regex-mgw41-1_34.a libboost_regex-mgw41-d-1_34.a libboost_regex-mgw41-mt-1_34.a libboost_regex-mgw41-mt-d-1_34.a libboost_regex-mgw41-mt-s-1_34.a libboost_regex-mgw41-mt-sd-1_34.a libboost_regex-mgw41-s-1_34.a libboost_regex-mgw41-sd-1_34.a

Suggestions?

Thanks,

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Scott Meyers

5:42 p.m.

David Daeschler wrote:

...

After following this thread lower down, I think that you're confusing -l (lower case l) and -L (capital L). Lower case -l specifies the individual library you are linking to (ex boost_filesystem). Capital -L specifies a directory or directories (you can use -L and -l as many times as you have to) where the linker should look for the libraries specified by the lower case -l's

Bobby Ward

5:46 p.m.

Fortunately/Unfortunately you have to specify the library as -lboost_regex-mgw41-1_34 or whatever variation due to boost's ABI compatibility requirements. On 5/30/07, Scott Meyers wrote:

...

David Daeschler wrote:

...
After following this thread lower down, I think that you're confusing -l (lower case l) and -L (capital L). Lower case -l specifies the individual library you are linking to (ex boost_filesystem). Capital -L specifies a directory or directories (you can use -L and -l as many times as you have to) where the linker should look for the libraries specified by the lower case -l's

No, this fails, too:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -Lc:\boost_current\lib -lboost_regex -lboost_f ilesystem

d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ld.exe: cannot find -lboost_regex collect2: ld returned 1 exit status

I've also tried variations making sure that the case of the paths in the command line matches what Windows shows (because, in the past, I've had trouble with Gnu tools treating paths case-sensitively on Windows). Still no luck.

Other suggestions?

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com http://www.bobbyrward.com http://combustion.sourceforge.net

Kenneth Laskoski

5:53 p.m.

On 5/30/07, Bobby Ward wrote:

...

Fortunately/Unfortunately you have to specify the library as

-lboost_regex-mgw41-1_34

or whatever variation due to boost's ABI compatibility requirements.

Right, but the direction to use -L is still valid. You have to do both things: D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -Lc:\boost_current\lib -lboost_regex-mgw41-1_34 -lboost_f ilesystem-mgw41-1_34 Kenneth

Scott Meyers

6:38 p.m.

Bobby Ward wrote:

...

Fortunately/Unfortunately you have to specify the library as

-lboost_regex-mgw41-1_34

Hoo-ray, it finally works. Thanks very much for this crucial information. FWIW, use of the LIBRARY_PATH environment variable works, too, so my successful command line looks like this: D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_regex-mgw41-1_34 -lboost_filesystem-mg w41-1_34 While trying to resolve this issue, I noticed during my search of the Boost User newsgroup that I was only one of several people having difficulty getting Boost to link with gcc, especially because, IIUC, things changed from 1.33 to 1.34. Better documentation would help. For example, http://www.boost.org/more/getting_started/windows.html says "On Windows, append a version number even if you only have one version installed (unless you are using the msvc or gcc toolsets, which have special version detection code) or auto-linking will fail." This strongly suggests that gcc supports auto-linking in a manner similar to MSVC, so I was surprised that what worked for MSVC did not work for gcc. Later on that page I read "Most Windows compilers and linkers have so-called “auto-linking support," and since g++ is commonly used on Windows, I assumed that it fell into the "Most Windows compilers" category. It would be nice if that page didn't limit its examples to MSVC. I know it's not practical to cover all possible compilers, but it seems to me that the big two are VC++ and gcc, so it'd be nice to have examples using both front and center. Thanks for all for your help. Scott

Bobby Ward

6:54 p.m.

Actually...

...

A note to Cygwin http://www.cygwin.com/ and MinGW http://mingw.org/users

...

If you plan to use your tools from the Windows command prompt, you're in the right place. If you plan to build from the Cygwinhttp://www.cygwin.com/bash shell, you're actually running on a POSIX platform and should follow the instructions for getting started on Unix variantshttp://www.boost.org/more/getting_started/unix-variants.html. Other command shells, such as MinGW http://mingw.org/'s MSYS, are not supported—they may or may not work.

On 5/30/07, Scott Meyers wrote:

...

Bobby Ward wrote:

...
Fortunately/Unfortunately you have to specify the library as

-lboost_regex-mgw41-1_34

Hoo-ray, it finally works. Thanks very much for this crucial information. FWIW, use of the LIBRARY_PATH environment variable works, too, so my successful command line looks like this:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_regex-mgw41-1_34 -lboost_filesystem-mg w41-1_34

While trying to resolve this issue, I noticed during my search of the Boost User newsgroup that I was only one of several people having difficulty getting Boost to link with gcc, especially because, IIUC, things changed from 1.33 to 1.34. Better documentation would help. For example, http://www.boost.org/more/getting_started/windows.html says "On Windows, append a version number even if you only have one version installed (unless you are using the msvc or gcc toolsets, which have special version detection code) or auto-linking will fail." This strongly suggests that gcc supports auto-linking in a manner similar to MSVC, so I was surprised that what worked for MSVC did not work for gcc. Later on that page I read "Most Windows compilers and linkers have so-called "auto-linking support," and since g++ is commonly used on Windows, I assumed that it fell into the "Most Windows compilers" category.

It would be nice if that page didn't limit its examples to MSVC. I know it's not practical to cover all possible compilers, but it seems to me that the big two are VC++ and gcc, so it'd be nice to have examples using both front and center.

Thanks for all for your help.

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com http://www.bobbyrward.com http://combustion.sourceforge.net

Scott Meyers

7:07 p.m.

Bobby Ward wrote:

...

Actually...

...
A note to Cygwin http://www.cygwin.com/ and MinGW http://mingw.org/ users

...
If you plan to use your tools from the Windows command prompt, you're in the right place.

That would be me. I built gcc using msys, but I'm using the vanilla Windows command window to build programs with gcc. Anyway, that pseudo-disclaimer doesn't change what the rest of the document implies about gcc and auto-linking, IMO. Scott

Bobby Ward

7:13 p.m.

You're right of course. I mistakenly assumed you were using MSYS. On 5/30/07, Scott Meyers wrote:

...

Bobby Ward wrote:

...
Actually...

...
A note to Cygwin http://www.cygwin.com/ and MinGW http://mingw.org/ users

...
If you plan to use your tools from the Windows command prompt, you're in the right place.

That would be me. I built gcc using msys, but I'm using the vanilla Windows command window to build programs with gcc.

Anyway, that pseudo-disclaimer doesn't change what the rest of the document implies about gcc and auto-linking, IMO.

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com http://www.bobbyrward.com http://combustion.sourceforge.net

Bobby Ward

7:16 p.m.

I just realized you are using mingw gcc4. Mingw doesn't support gcc4 and you are generally advised to stay away from it for many reasons. gcc 4 remove #pragma comment(lib, "") support which is why auto-linking doesn't work. On 5/30/07, Bobby Ward wrote:

...

You're right of course. I mistakenly assumed you were using MSYS.

On 5/30/07, Scott Meyers wrote:

...
Bobby Ward wrote:

...
Actually...

...
A note to Cygwin < http://www.cygwin.com/> and MinGW http://mingw.org/ users

...
If you plan to use your tools from the Windows command prompt, you're in the right place.

That would be me. I built gcc using msys, but I'm using the vanilla Windows command window to build programs with gcc.

Anyway, that pseudo-disclaimer doesn't change what the rest of the document implies about gcc and auto-linking, IMO.

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com

http://www.bobbyrward.com http://combustion.sourceforge.net

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com http://www.bobbyrward.com http://combustion.sourceforge.net

Scott Meyers

7:52 p.m.

Bobby Ward wrote:

...

I just realized you are using mingw gcc4. Mingw doesn't support gcc4 and you are generally advised to stay away from it for many reasons.

I like the fact that it lets me play with gcc TR1 support. Scott

Bobby Ward

8:05 p.m.

...

Exceptions cannot leave DLLs. This issue was fixed in the official MinGW releases with a local patch for the 3.4 series, but is not fixed in the main GCC sources. The problem only appears when a function in a DLL called from outside the DLL throws (or fails to catch) an exception, and results in

Admittedly that's the part I hate most about having to use gcc3 BUT there's the problem about throwing exceptions across dll boundaries. program termination at that point. Seeing as all boost libraries are built as dlls(as far as I am aware) this proves problematic. On 5/30/07, Scott Meyers wrote:

...

Bobby Ward wrote:

...
I just realized you are using mingw gcc4. Mingw doesn't support gcc4 and you are generally advised to stay away from it for many reasons.

I like the fact that it lets me play with gcc TR1 support.

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com http://www.bobbyrward.com http://combustion.sourceforge.net

Jonathan Franklin

8:09 p.m.

On 5/30/07, Bobby Ward wrote:

...

Seeing as all boost libraries are built as dlls(as far as I am aware) this proves problematic.

By default, they're built both ways. I actually use the static versions w/ the MSVC compiler. Jon

David Daeschler

8:12 p.m.

Hi Bobby,

...

Admittedly that's the part I hate most about having to use gcc3 BUT there's the problem about throwing exceptions across dll boundaries.

The good news is that according to the MinGW mailing list, the maintainers will soon be releasing their port of GCC 4.2 that deals with that issue and many others. We use MinGW for the windows build of our product, and as such I have been anxiously awaiting the upcoming release. On Wed, 2007-05-30 at 14:05 -0600, Bobby Ward wrote:

...

Admittedly that's the part I hate most about having to use gcc3 BUT there's the problem about throwing exceptions across dll boundaries.

...
Exceptions cannot leave DLLs. This issue was fixed in the official MinGW releases with a local patch for the 3.4 series, but is not fixed in the main GCC sources. The problem only appears when a function in a DLL called from outside the DLL throws (or fails to catch) an exception, and results in program termination at that point.

Seeing as all boost libraries are built as dlls(as far as I am aware) this proves problematic.

On 5/30/07, Scott Meyers wrote: Bobby Ward wrote: > I just realized you are using mingw gcc4. Mingw doesn't support gcc4 > and you are generally advised to stay away from it for many reasons.

I like the fact that it lets me play with gcc TR1 support.

Scott

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Bobby R. Ward ------------------------------ bobbyrward@gmail.com

http://www.bobbyrward.com http://combustion.sourceforge.net _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Kenneth Laskoski

7:39 p.m.

...

use of the LIBRARY_PATH environment variable works, too

Yes, this turns the -L option obsolete. Kenneth

David Abrahams

31 May 31 May

12:04 a.m.

on Wed May 30 2007, Scott Meyers wrote:

...

Bobby Ward wrote:

...
Fortunately/Unfortunately you have to specify the library as

-lboost_regex-mgw41-1_34

Hoo-ray, it finally works. Thanks very much for this crucial information. FWIW, use of the LIBRARY_PATH environment variable works, too, so my successful command line looks like this:

D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -lboost_regex-mgw41-1_34 -lboost_filesystem-mg w41-1_34

While trying to resolve this issue, I noticed during my search of the Boost User newsgroup that I was only one of several people having difficulty getting Boost to link with gcc, especially because, IIUC, things changed from 1.33 to 1.34. Better documentation would help. For example, http://www.boost.org/more/getting_started/windows.html says "On Windows, append a version number even if you only have one version installed (unless you are using the msvc or gcc toolsets, which have special version detection code) or auto-linking will fail." This strongly suggests that gcc supports auto-linking in a manner similar to MSVC,

...oooh, I didn't see that one coming. Would you please enter a Trac ticket for that problem at svn.boost.org and assign it to me?

...

so I was surprised that what worked for MSVC did not work for gcc. Later on that page I read "Most Windows compilers and linkers have so-called “auto-linking support," and since g++ is commonly used on Windows, I assumed that it fell into the "Most Windows compilers" category.

Ah. So, BTW, are you using cygwin or mingw?

...

It would be nice if that page didn't limit its examples to MSVC. I know it's not practical to cover all possible compilers, but it seems to me that the big two are VC++ and gcc,

Really, VC++ is the BIG ONE. Something like 95% of all C++ programmers are using it, according to a very reliable source.

...

so it'd be nice to have examples using both front and center.

It was my educated guess that most people using gcc on windows were using Cygwin and trying to build from the cygwin bash prompt, which according to the getting started guide, would have them following the directions at http://boost.org/more/getting_started/unix-variants.html even when building on Windows. That document shows only examples that will work with g++. I really had to strongly resist adding alternative cases in writing this getting started guide in order to keep it simple. I'm reluctant to add g++, because then someone will ask why there are no examples for borland, intel, DMC++, etc... it's a slippery slope. But you're a master of writing understandable tutorials... if you can suggest specific changes that don't undermine the simplicity of the document I'll happily apply them. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Jonathan Franklin

30 May 30 May

5:50 p.m.

Try this: g++ -Wall -O3 -ID:/C++/Boost/Current -o boostbuildtest.exe boostbuildtest.cpp -Lc:/boost_current/lib -lboost_regex -lboost_filesystem If this fails, then get a directory listing of c:/boost_current/lib and see if your library files don't have any extra chars in them, like -mt or 1.34etc. So if my libdir contains libboost_date_time-gcc41-mt-d.so, I would specify -lboost_date_time-gcc41-mt-d on the command line. Hope this helps. Jon

Jonathan Franklin

5:53 p.m.

On 5/30/07, Jonathan Franklin wrote:

...

Try this: g++ -Wall -O3 -ID:/C++/Boost/Current -o boostbuildtest.exe boostbuildtest.cpp -Lc:/boost_current/lib -lboost_regex -lboost_filesystem

Note that I have had issues specifying paths w/ '\' as the delimiter, but I use cygwin, so this is probably a bash issue and not a problem when building from a Windows command prompt. Jon

Richard

6:17 p.m.

I know nothing about unix so this could be a useless suggestion. I think in the unix world they use '/' to separate directories (rather than '\'). Is that relevant? - Richard -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Scott Meyers Sent: 30 May 2007 18:42 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Specifying library locations for g++ David Daeschler wrote:

...

After following this thread lower down, I think that you're confusing -l (lower case l) and -L (capital L). Lower case -l specifies the individual library you are linking to (ex boost_filesystem). Capital -L specifies a directory or directories (you can use -L and -l as many times as you have to) where the linker should look for the libraries specified by the lower case -l's

No, this fails, too: D:\Temp>g++ -Wall -O3 -ID:\C++\Boost\Current -o boostbuildtest.exe boostbuildtest.cpp -Lc:\boost_current\lib -lboost_regex -lboost_f ilesystem d:\apps\msys\1.0\mingw\bin\..\lib\gcc\mingw32\4.1.1\..\..\..\..\mingw32\bin\ ld.exe: cannot find -lboost_regex collect2: ld returned 1 exit status I've also tried variations making sure that the case of the paths in the command line matches what Windows shows (because, in the past, I've had trouble with Gnu tools treating paths case-sensitively on Windows). Still no luck. Other suggestions? Scott _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.3/824 - Release Date: 29/05/2007 13:01 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.3/824 - Release Date: 29/05/2007 13:01

6377

Age (days ago)

6378

Last active (days ago)

List overview

Download

23 comments

9 participants

participants (9)

Bobby Ward
David Abrahams
David Daeschler
Jonathan Franklin
Kenneth Laskoski
KSpam
Richard
Scott Meyers
Vladimir Prus