22 Aug
2003
22 Aug
'03
2:24 p.m.
Ingo Oeser <ingo.oeser(a)informatik.tu-chemnitz.de> writes:
Surely not the compiler, itself. Perhaps in a compiler-related
library. Or, maybe glibc could export this stuff.
Actually, my Debian system has two copies in different C++ header
directories, probably because I have several compiler packages
installed...
libstdc++5-dev: /usr/include/c++/3.2/i386-linux/bits/atomicity.h
libstdc++3-dev: /usr/include/g++-v3/i386-linux/bits/atomicity.h
I would actually prefer a separate LGPL-ed package supporting as many
architectures as reasonably possible. That would make application
code easier to port to non-GCC, non-glibc, or non-Linux platforms.
The main reason I don't want to include all these files in my own
sources is that I have no reasonable way to test or maintain all those
snippets of assembler language for exotic machines to which I have no
access.
I'd love to see a small team with access to a suite of test machines
step up to supporting these functions on as many machines as possible.
I wouldn't mind doing a lot of that work, myself. But I couldn't do
an adequate job without access to additional resources and help from
people familiar with various processor architectures.
A carefully chosen set of these header files with a library of test
cases and good documentation would be a valuable resource for the open
software community in general, and LAD in particular. In fact, I'm
surprised no one has done this already. I guess people with the
needed expertise and access to those sorts of machine resources have
bigger fish to fry.
Regards,
--
Jack O'Quin
Austin, Texas, USA
To compile my
application for all supported platforms, I would need to
collect all these header files and wrap them with appropriate
#ifdef's, right? Or else, I could put them in subdirectories and
select the right one at ./configure time.
Yes, there is no other way to include that kind of code.
This kind of code should actually be in the compiler, but they
don't seem to care.