Boost Filesystem Build On GCC

When Boost Filesystem is built with bjam "-sTOOLS=gcc" or bjam "-sTOOLS=mingw" on MinGW, the resulting static library is a .lib consisting of .obj files. However, it is traditional for gcc to use .a files which consist of .o files. I fix this by hand by renaming the .obj files to .o and then executing ar rvs libboost_filesystem.a *.o , but it would be nice if bjam would get it correctly by itself. Stephan T. Lavavej http://nuwen.net

"Stephan T. Lavavej" <stl@caltech.edu> writes:
When Boost Filesystem is built with bjam "-sTOOLS=gcc" or bjam "-sTOOLS=mingw" on MinGW, the resulting static library is a .lib consisting of .obj files. However, it is traditional for gcc to use .a files which consist of .o files. I fix this by hand by renaming the .obj files to .o and then executing ar rvs libboost_filesystem.a *.o , but it would be nice if bjam would get it correctly by itself.
You need to use a cygwin build of bjam if you want cygwin-protocol file extensions. Cheers, -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams:
"Stephan T. Lavavej" <stl@caltech.edu> writes:
When Boost Filesystem is built with bjam "-sTOOLS=gcc" or bjam "-sTOOLS=mingw" on MinGW, the resulting static library is a .lib consisting of .obj files. However, it is traditional for gcc to use .a files which consist of .o files. I fix this by hand by renaming the .obj files to .o and then executing ar rvs libboost_filesystem.a *.o , but it would be nice if bjam would get it correctly by itself.
You need to use a cygwin build of bjam if you want cygwin-protocol file extensions.
Or he may override them from command line: bjam -sTOOLS=mingw -sSUFLIB=.a -sSUFDLL=.dll -sSUFOBJ=.o (Well, at least sSUFLIB and -sSUFDLL seems to work. I haven't tried -sSUFOBJ yet, as I was only interested in having the built libraries named for easier inclusion in my projects' makefiles.) Care to enlighten a newbie as to why you call these file extensions cygwin-protocol? I can't think of any libraries apart from Boost, whether compiled using MSYS or plain MinGW, that don't use them. Then again, Boost is the only one I've compiled using bjam. I thought these extensions where a general convention for g++ irrespective of build environment. Kind regards, Daniel Schlyder -- http://bitblaze.com/

At 06:22 PM 2/14/2004, David Abrahams wrote:
"Stephan T. Lavavej" <stl@caltech.edu> writes:
When Boost Filesystem is built with bjam "-sTOOLS=gcc" or bjam "-sTOOLS=mingw" on MinGW, the resulting static library is a .lib consisting of .obj files. However, it is traditional for gcc to use .a files which consist of .o files. I fix this by hand by renaming the .obj files to .o and then executing ar rvs libboost_filesystem.a *.o , but it would be nice if bjam would get it correctly by itself.
You need to use a cygwin build of bjam if you want cygwin-protocol file extensions.
It has become clear that when people build Boost.Filesystem using GCC on Windows, there are two different expectations: 1) It will behavior like any other Windows app built with any other Windows compiler. Cygwin and/or Mingw may be installed, but that doesn't imply any change in behavior compared to if they weren't installed. (That's how the library behaves now.) 2) The library should behave according to Cygwin's ability to allow a program to pretend it is running on a POSIX-style operating system. Both of these seem valid, so the library needs a configuration mechanism to tell it which is desired. Tests have to be altered to verify both flavors work correctly. Is there a second dimension - Running under cmd or running under bash? I don't have a clear understanding of that and would appreciate guidance or opinions. --Beman
participants (4)
-
Beman Dawes
-
Daniel Schlyder
-
David Abrahams
-
Stephan T. Lavavej