This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: AIX atomicity.h support
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: AIX atomicity.h support
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 25 Sep 2000 13:19:24 -0700 (PDT)
- cc: libstdc++ at sources dot redhat dot com, Mark Mitchell <mark at codesourcery dot com>, Geoff Keating <geoffk at cygnus dot com>
Hi David.
Have you been able to get libstdc++-v3, with this patch, to build on AIX?
> Would the following patch be acceptable to allow v3 to use an AIX
> OS-specific version of atomicity.h instead of an architecture-specific
> one? The CPU_FLAGS hack only covers up the symptom on newer,
> PowerPC-based RS/6000 systems, it does not solve the problem: it is
> invalid to have PowerPC code in common-mode libraries.
I'm intersted in allowing a cpu or os abstraction layer for atomicity
actions. As such, I have no objections to this general direction.
> I sent an AIX implementation of atomicity.h
> (config/aix/bits/atomicity.h, not config/powerpc/bits/atomicity.h) last
> May.
can you resend this and include it in the next iteration of your patch
please?
> Current the config/cpu directories only contain bits/atomicity.h.
> I do not know whether it is better to point cpu_include_dir at the os
> directory or to point it at some empty directory and let CPP find the file
> in config/aix/bits/atomicity.h.
I suspect the easier bit will be to pass in a NULL cpu_include_dir and
instead just go with the os-specific stuff in config/aix/bits
> I am not sure what to do about src/Makefile.am:myinstallheaders
> installing $(cpu_headers) either.
You will probably have to make this conditional. The libio/Makefile.am has
some examples of how to do this, based on the results of configure.
best,
benjamin