Problems of cross compiling: ar and ranlib tools naming

I'm trying to build full cross compiled toolchain and boost is almost ok, except of some details in static libs. The problem is that it uses patterns like $(command-string) -print-prog-name=ar (and ranlib as well) for getting the ar and ranlib for the toolset. But due to some bug in i686-w64-mingw32 and a whole bunch of similar instruments (on debian, ubuntu, etc) the XXX-gcc -print-prog-name=ar returns simply "ar", without tool prefix. Same about ranlib. And they seem not being apt to fix it: http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/8... I saw an old bug ticket about this problem in old boost archives: https://svn.boost.org/trac/boost/ticket/3373 It's marked as fixed. I added some strings to my project-config.jam like: using gcc : : i686-w64-mingw32-gcc : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar <ranlib>i686-w64-mingw32-ranlib But it evidently had no effect, by some reason: in output I still see strings like "/usr/bin/ar", "usr/bin/ranlib" and the librarian error ("could not read symbols: Archive has no index; run ranlib to add one") is still there when trying to use the libraries. I found the place in gcc.jam tool script where ar-tool name is defined: # - The archive builder. local archiver = [ common.get-invocation-command gcc : [ NORMALIZE_PATH [ MATCH "(.*)[$(nl)]+" : [ SHELL "$(command-string) -print-prog-name=ar" ] ] ] : [ feature.get-values <archiver> : $(options) ] : $(bin) : search-path ] ; toolset.flags gcc.archive .AR $(condition) : $(archiver[1]) ; if $(.debug-configuration) { ECHO notice: using gcc archiver :: $(condition) :: $(archiver[1]) ; } ranlib is similar, windres is kind of case of some variants. I'm not that smart in boost build scripts but it looks like it tries to get the name from -print-prog-name (that is buggy). Am I correct? Maybe I'm just setting parameters in some wrong way? I would like to get some hints how I could make it take my options from project-config.jam and take the -print-prog-name by default. To get the resulting tools strings like i686-w64-mingw32-ar, etc, be it a parameters setting or patch for tools jam file, whatever that solves the problem. Sincerely, Yana A. Kireyonok

On Fri, Nov 25, 2011 at 7:04 PM, Iron Bug
I'm trying to build full cross compiled toolchain and boost is almost ok, except of some details in static libs. The problem is that it uses patterns like
$(command-string) -print-prog-name=ar (and ranlib as well)
for getting the ar and ranlib for the toolset.
But due to some bug in i686-w64-mingw32 and a whole bunch of similar instruments (on debian, ubuntu, etc) the XXX-gcc -print-prog-name=ar returns simply "ar", without tool prefix. Same about ranlib. And they seem not being apt to fix it:
... You might want to look at mingw-cross-env [1] which includes boost. It doesn't have 64-bit support yet though. There's a link there to browse the development version. Look for file src/boost.mk if you want to see the boost recipe. Mark [1] http://mingw-cross-env.nongnu.org/
participants (2)
-
Iron Bug
-
Mark Brand