Re: [boost] [Boost-build] [1.35.0] Threads - build failure using gcc on Win XP

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-04-24 14:53:56

On Tue, Apr 22, 2008 at 3:27 PM, Roland Schwarz
<roland.schwarz_at_[hidden]> wrote:
>
>
> Vladimir Prus wrote:
> > You can use cygwin gcc in both cygwin mode and -mno-cygwin mode. What
> > default threading api do you expect for the latter case, and can it be
> > inferred in any way from output of -dumpmachine?
>
> The default api possibly should be win32 in the latter case. In
> principle it could be infered from -dumpmachine by evaluating
> the flavor which would be in that case:
> i686_pc_mingw32

When building gcc from sources under cygwin, one begins with a call to
configure. I recently used the following invocation:

configure --enable-threads=posix --disable-bootstrap
  --prefix=/opt/gcc-4.3.0 --enable-languages=c++

Actually, at first I mistakenly forgot to pass an --enable-threads
parameter. I was made aware of this when I tried to build boost and
found that the BOOST_DISABLE_THREADS was being #defined (good
auto-detection work by the boost/config machinery I presume). After
starting over by configuring gcc with --enable-threads=posix before
building it all was well. Now I haven't tried this, but preliminary
googling tells me that it is also possible to configure gcc with
--enable-threads=win32. My first questions are:

  1) Does setting --enable-threads=win32 affect the eventual output of
  -dumpmachine?

  2) If not, how could such a gcc fit into the flavor scheme?

You may tell me that --enable-threads=win32 cannot be made to work
without also setting other flags until one ends up with what is
essentially a mingw compiler, but I haven't studied things carefully
enough yet to see whether this is true.

Stepping back a little, a more fundamental question occurs to me:

   3) Why does the thread Jamfile.v2 need to know the default
   threading model?

Here's why I ask:

(What follows may be wrong, since I don't know all the corners of the
build system.)

Today, for example, if I compile on a powerpc mac without specifically
selecting the architecture or address-model, I get no mention of
either in my paths or in my mangled library names. The build system
will silently use the architecture of the host machine. If I compile
the same code on an Intel mac, the build system uses the same folder
and library names IIUC, but the generated code will use x86
instructions. I believe one has to parse the output from a tool that
lives outside of the build system, such as arch, to determine what the
resulting instruction set will be in this scenario. That is, I'm not
aware of a way to treat the default architecture as a property that
can be used in conditionals, except in the case where the user
specifically asks for, say, architecture=x86. Am I correct here?

Maybe this isn't just a mac issue. If the user doesn't explicitly
mention target-os I am unaware of how to successfully add library
usage-requirements like:

  <toolset>gcc,<architecture>x86: <instruction-set>i486

## require intrinsic support for patched cygwin compatible Intel TBB

  4) If I'm wrong here, how do I do this? This is actually coming up
  in our code base today

Ideally I'd like to be able to narrow this to a conditional that
implements:

 IF (toolset = gcc and target-os = cygwin and architecture = x86) then
  ensure that instruction-set is at least i486

but I'm unaware as to how to do it.

In any case, the point of all this is that, from what I can gather,
the build system really doesn't have all of this information at
present. This leads me to ask:

  5) Would it be possible or desirable to give up a little 'safety' in
  return for a simpler thread Jamfile?

Such a Jamfile would only add the state of the threadapi feature
(different from none) to the path in the case when the user explicitly
sets threadapi. This way it wouldn't have to try to (imperfectly)
duplicate the logic in the boost/config headers, but it could still
offer a way for the user to manually override them when necessary.

I can see several benefits if the answer to question 5 turns out to be
yes.

  A) Thread's Jamfile's dependence on who compiled the bjam.exe tool
  would go away

  B) Maybe some of the need for enhanced flavor support is lessened (I
  have no idea whether this is true)

  C) Paths could be made somewhat shorter and shell independent

I would like to digress for a moment to relate a small anecdote about
how long paths are not simply an aestehetic nuisance, but can increase
development costs. Currently to be able to use 1.35.0 threads from an
msvc-compiled bjam under from bash, I have to have my users add

toolset.add-requirements
  <toolset>gcc:<target-os>cygwin
  <toolset>gcc:<threadapi>pthread ;

to their user-config.jam

While allowing threads to build, in our environment this has the
side-effect of producing paths like the following:

C:\opensource\sanbox\joeuser\sandbox\built_artifacts\test\
unit_tests\copy_on_write\copy_on_write_test.test\gcc-4.3.0\debug\
architecture-x86\asl-dev\instruction-set-i486\link-static\
target-os-cygwin\threadapi-pthread\threading-multi\
copy_on_write_test.exe

Yesterday this bit us. Apparently, on some users' machines the full
path length exceeds the cygwin/XP limits and the executable can not be
run! So the tests in our Jamfile were mysteriously failing. One remedy
here seems to be to use shorter paths for our own features,
directories and project names. Another is to try to pass
--abbreviate-paths to bjam to drop a few vowels from the paths. A
third is to perhaps use a cygwin-built bjam. For various reasons none
of these have much appeal, though I'll do what I can. Ideally, though,
I'd like target-os-cygwin and threadapi-pthread to disappear from the
path, since they don't add much value for me. In fact, I argue that
they remove value, since they are not present in the paths that I get
if I happen to choose a cygwin-compiled bjam.exe, so I end up with two
needlessly incompatible trees of artifacts.

This has been a long email with several different kinds of questions,
and a number of guesses about the behavior of the build system. Some
of my assumptions are undoubtedly wrong. But, if there is interest,
I'd like hear several other people's thoughts on these issues. And of
course answers to any of my questions are most welcome.

-Mat