[libcxx] Handling multi-platform configuration.

I recently started porting libc++ over to MinGW and have discovered
just how complicated configuration is going to be. Even ignoring
locale, there are huge differences in support and style between MinGW,
the Microsoft C Runtime, POSIX.1-2008 (IEEE Std 1003.1™-2008 (The Open
Group Technical Standard Base Specifications, Issue 7)), and all the
other platforms out there. For example, the version of cerrno I came
up with (attached) that is standard compliant is about 800 lines long
just to properly deal with all the errno.h macros that aren't in the C
standard and various platforms don't define, but C++0x requires. This
is simple compared to some of the other configuration issues we have
to deal with, like locale.

The most common solution to this problem is pre-build configuration
based on the host platform and compiler; however this does not work
well for the standard library because it should be usable with any
supported compiler without rebuilding or specifying extra parameters.
It should always Just Work.

libc++ currently solves a subset of this problem, compiler
differences, with the __config header. This is a manually maintained
header that defines various macros for features that are not
supported. This works currently, but I feel that when we add more
compilers and platforms (and versions thereof) this will become
unmaintainable. Complex configurations like this are why autoconf and
the like were created. However, as stated above, we can't configure at
libc++ build time. It has to be at include time, which means using the
preprocessor.

I propose that instead of trying to write a program in C Preprocessor,
we write it in a real language which generates C Preprocessor for us.
The key difference between this and autoconf is that the generated
__config header file is platform independent. Similar to how no matter
what platform you run tblgen on, you get the same output.

I don't currently have a proposal for what language to actually use
other than something declarative like tablegen. The important part is
that the total effort of maintaining the generator + config is less
than maintaining a C Preprocessor version of the config.

- Michael Spencer

cerrno-pp.patch (18.6 KB)

Michael Spencer wrote:

I recently started porting libc++ over to MinGW and have discovered
just how complicated configuration is going to be. Even ignoring
locale, there are huge differences in support and style between MinGW,
the Microsoft C Runtime, POSIX.1-2008 (IEEE Std 1003.1™-2008 (The Open
Group Technical Standard Base Specifications, Issue 7)), and all the
other platforms out there. For example, the version of cerrno I came
up with (attached) that is standard compliant is about 800 lines long
just to properly deal with all the errno.h macros that aren't in the C
standard and various platforms don't define, but C++0x requires. This
is simple compared to some of the other configuration issues we have
to deal with, like locale.
  

Hi Michael,

This is *exactly* why it would be greatly appreciated if people would help improve stdcxx [1] instead of trying to just write everything from scratch. Regardless whatever superficial evaluation has been done I'd kindly ask any volunteers to reevaluate this.

Martin, on cc, who worked on this codebase for 10 years and is on the C++ standards committee can chime in if he likes.

(Apologies for not being able to help contribute a direct solution to your above problem.)

Best,

./C

[1] http://stdcxx.apache.org/

Unfortunately, the stdcxx library is under the Apache License 2.0, which
is not acceptable for many people, projects and companies. (Note I am
*not* saying anything about the quality of it, which may very well be
excellent; I haven't looked at that.)

Also, the "Why a new C++ Standard Library for C++'0x?" FAQ on the libc++
site says:

"STLport and the Apache libstdcxx library are two other popular
candidates, but both lack C++'0x support. Our experience (and the
experience of libstdc++ developers) is that adding support for C++0x (in
particular rvalue references and move-only types) requires changes to
almost every class and function, essentially amounting to a rewrite.
Faced with a rewrite, we decided to start from scratch and evaluate
every design decision from first principles based on experience."

Dimitry Andric wrote:

This is *exactly* why it would be greatly appreciated if people would
help improve stdcxx [1] instead of trying to just write everything from
scratch. Regardless whatever superficial evaluation has been done I'd
kindly ask any volunteers to reevaluate this.

Martin, on cc, who worked on this codebase for 10 years and is on the
C++ standards committee can chime in if he likes.

Unfortunately, the stdcxx library is under the Apache License 2.0, which
is not acceptable for many people, projects and companies.

The Apache license is very permissive and can you give an example of a company/person/project it's not acceptable for? Is there any company/person contributing to libcxx now that can't use it? (It's certainly not GPL, allows binary only distribution and can't please everyone all of the time..)

(Note I am
*not* saying anything about the quality of it, which may very well be
excellent; I haven't looked at that.)

Also, the "Why a new C++ Standard Library for C++'0x?" FAQ on the libc++
site says:

"STLport and the Apache libstdcxx library are two other popular
candidates, but both lack C++'0x support. Our experience (and the
experience of libstdc++ developers) is that adding support for C++0x (in
particular rvalue references and move-only types) requires changes to
almost every class and function, essentially amounting to a rewrite.
Faced with a rewrite, we decided to start from scratch and evaluate
every design decision from first principles based on experience."

Yeah I've seen that FAQ and that's why I asked people to reevaluate this. Whoever looked into this really didn't take into account some things on both sides.

a) STDCXX - The amount of work to extend for a single platform/arch is much less than has been suggested
b) The amount of work to get to the level of production quality across multiple platforms has been greatly underestimated
c) Others who are already using STDCXX are much more likely to help with that than move to a new STL (HP/PathScale/Sun/Roguewave. etc)

The GPLv2 is incompatible with the Apache license (due to the patent clause in Apache and the no extra conditions clause in GPLv2), meaning that no GPLv2 software can be distributed linking to it. You could possibly get around this with the system library exemption in GPLv2, clause 3, but only if libstdcxx were distributed with the core OS - if it is an optional package then this exemption would not apply. The system library exemption is generally assumed not to apply to code that is part of the OS, so Apple or FreeBSD could not ship libstdcxx as the system C++ library implementation and also ship GPL'd C++ utilities that used it.

The Apache license is compatible with GLPv3, so this is not a problem for any software with the 'or later' clause, as long as all of its other dependencies are GPLv3 compatible (which, for example, LGPLv2.1 isn't).

Disclaimer: I am not a lawyer, this is not legal advice, if you want legal advice, you should consult a lawyer, any problems that you encounter from treating this as legal advice are your own fault...

David

-- Sent from my brain

David Chisnall wrote:

The stdcxx configuration machinery is very simple and quite
powerful. The library itself has been ported to dozens of
compiler and operating system combinations (including Cygwin).
Portability was one of the major goals of the implementation
back when Rogue Wave was selling it and I think we did a good
job there.

Unfortunately, the library hasn't been touched in a couple of
years and there are only beginnings of C++ 0x support. I've
been busy with my day job and the ASF process makes it hard
for new people to start contributing changes to it (you have
to submit seveal substantial patches over a period of weeks
or even months to get commit privileges).

The C++ 0x effort is substantial, but it's far from a complete
rewrite. The iostream and localization libraries alone are
multi-year projects (as a data point, IIRC, a complete locale
rewrite took Rogue Wave close to 2 years to finish). That said
it's always nice to be able to start from scratch and not have
to worry about compatibility.

I'd love to see someone revive stdcxx and implement C++ 0x.
I'd even be willing to help, but I don't see it happening at
the ASF. The project would probably have to be forked and done
somewhere else.

FWIW, the ASF is only licensing stdcxx from Rogue Wave. I don't
know much about these things but it seems that it should be
possible to get another free license from Rogue Wave for this
project. Alternatively, since without active development the
ASF is going to have to retire the project, it might be possible
to work out some sort of an arrangement with them whereby they
give up their license to keep the project alive. Being the VP
of the project at the ASF I could try to facilitate it.

Martin

If someone wants a GPL compatible version they already have the GNU implementation.

Then they have to maintain two C++ library implementations in the base system, and programs need to make sure that they are using the one that the libraries that they depend on are linked against, which would cause huge headaches (more so than having a single break-the-word migration).

Isn't that a big part of reason people are working on this? (By "this" I mean to move away from GPL2 and especially v3) Isn't FreeBSD trying to make v9 or v10 fully GPL free in the base system? I'd say doing this would be a strong move in that direction..

There are still a few GPL'd C++ things in the FreeBSD base system, so they could replace libstdc++ with libc++, but if they imported libstdcxx then they'd need to replace all of these things at the same time, which makes incremental replacement harder.

Some downstream projects from FreeBSD (e.g. PC-BSD) also ship some GPL'd C++ tools that would not qualify for the system library exemption with an Apache licensed C++ lib.

David

-- Send from my Jacquard Loom

Hi Guys,

While I appreciate the professionalism in your approach, the stdcxx library is off-topic here. No one wishes anything bad to happen to stdcxx and there is certainly room for multiple library implementations. However, that is independent of the future of libc++, and Michael's patches seem like a great step forward. Discussion about one vs the other can happen on a generic c++ forum.

-Chris