| Summary: | linux26-headers breaks compilation of cppvm programs using cppvmBarrier::barrier() | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ed Hein <tyger> |
| Component: | [OLD] Library | Assignee: | Tim Yamin (RETIRED) <plasmaroo> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | hp-cluster |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
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. OK, check out 3.4.5 Please try 3.4.5. |
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.