Bug 61017 - linux26-headers breaks compilation of cppvm programs using cppvmBarrier::barrier()
|
Bug#:
61017
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: TEST-REQUEST
|
Assigned To: plasmaroo@gentoo.org
|
Reported By: tyger@gmx.de
|
|
Component: Library
|
|
|
URL:
|
|
Summary: linux26-headers breaks compilation of cppvm programs using cppvmBarrier::barrier()
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2004-08-20 05:05 0000
|
When I try to compile sources using the cppvm library and e.g. signal.h, the
macros in linux26-headers interfere with internal functions.
Reproducible: Always
Steps to Reproduce:
1. compile any source using cppvmBarrier::barrier() while including e.g.
csignal or signal.h
#include <cppvm.h>
#include <csignal>
int main() {
cppvmBarrier tSyncPoint();
tSyncPoint.barrier();
}
Actual Results:
error: `__memory_barrier' undeclared
the macro barrier() substitutes the method barrier() by __memory_barrier
(see /usr/include/linux/compiler.h of linux26-headers)
Expected Results:
the macros should not interfere with external sources
This bug is related to bug #56885. While the latter is solved and cdrdao-1.1.8
compiles fine on my system, the macros defined in linux26-headers still
interfere with other sources.
Is this still a problem? If so, do you have a suggested fix for it?
Actually, there is a new bug introduced by
http://bugs.gentoo.org/show_bug.cgi?id=82614 . The standard PVM_ARCH=LINUX was
changed to PVM_ARCH=LINUXI386 by the s390-Patch. The bugfix corrects this by
creating appropriate config files for this ARCH, but cppvm still relies on
PVM_ARCH=LINUX.
After installing cppvm by manually symlinking LINUXI386 with LINUX at a few
spots, I was able to test the original bug.
The bug still exists, but with a different error message:
cppvm.c:6: error: expected unqualified-id before "asm"
cppvm.c:6: error: expected `;' before "asm"
I'm using linux26-headers-2.6.8.1-r2
Workaround: Don't use csignal/signal.h in your cppvm-Programs!
Possible fix: don't include compiler*.h in dependency tree of signal.h. Maybe
this is an upstream 'feature' in kernel sources.
Cya, Ed
I'm working on an update to pvm 3.4.5, hopefully that'll resolve a couple of
issues.
