Menu
▾
▴
#22 compile fails on SLES10:
I'm building on SUSE SLES10. This is one of those professional systems with really outdated (but stable) SW versions. :-)
These are the relevant pieces:
> rpm -q glibc kernel-smp glibc-2.4-31.77.84.1 kernel-smp-2.6.16.60-0.58.1.3835.0.PTF.638363
Building dmtcp fails with:
g++ -DHAVE_CONFIG_H -I. -fPIC -g -O2 -MT filewrappers.o -MD -MP -MF .deps/filewrappers.Tpo -c -o filewrappers.o filewrappers.cpp filewrappers.cpp: In function 'int readlink(const char*, char*, size_t)': filewrappers.cpp:562:52: error: declaration of C function 'int readlink(const char*, char*, size_t)' conflicts with /usr/include/unistd.h:773:16: error: previous declaration 'ssize_t readlink(const char*, char*, size_t)' here
Quick inspection of the code shows that ./dmtcp/src/syscallwrappers.h defines this:
#if __GLIBC_PREREQ(2,5) # define READLINK_RET_TYPE ssize_t #else # define READLINK_RET_TYPE int #endif
but the local version of readlink in glibc-2.4's /usr/include/unistd.h is defined as such:
extern ssize_t readlink (__const char *__restrict __path,
char *__restrict __buf, size_t __len)
__THROW __nonnull ((1, 2)) __wur;
If I change
#if __GLIBC_PREREQ(2,5)
to
#if __GLIBC_PREREQ(2,4)
the compile completes nicely.
I must say I do not know whether SUSE has modified these headers. I can just report what it is like on this system. (SLES10 is not quite EOL = end of life yet.)
Indeed, SUSE's headers differ from what I can see in glibc's 2.4 git:
and look more like what I find in glibc's 2.5 git. Sigh.
Perhaps an autoconf check for the return type of readlink would be more appropriate, if such is even possible.
Do close as irrelevant if you don't see a chance of fixing. (Might be worth a note in the docs.) That said, it doesn't build out-of-the-box for me on SLES11 either. More in a separate ticket.
Thanks for this bug report. We'll look at fixing this for compatibility
with SLES10. I'm guessing that you're using DMTCP version 1.2.7.
Is this the case?
Thanks,
- Gene
On Wed, Jul 03, 2013 at 09:17:34AM +0000, Moritz Barsnick wrote:
Related
Bugs: #22
Hi Moritz,
I was looking further into the compilation for SLES10/glibc-2.4.
It's all exactly as you say: the SLES10/glibc-2.4 declaration for readlink
is closer to that of glibc-2.5.
Since SLES10 is near end-of-life, and the compiler error message makes
it clear how the end user can patch this, I'm tempted to not put in special
conditionalizations or configure tests for this. But if I see similar
examples of this type of problem, I will fix this issue.
Hence, I'm really interested in your other statement:
Thanks,
- Gene
On Wed, Jul 03, 2013 at 09:17:34AM +0000, Moritz Barsnick wrote:
Related
Bugs: #22
Hi Gene,
thanks for looking at it.
I agree, it's probably not worth fixing for this one scenario. I disagree though that it's obvious to the user. (It wasn't to me, and I'm a programmer/power builder. :-)) I would at least recommend a note in the appropriate documentation.
I promise to follow up on the SLES11 issue. Glad to see you're interested.
Hi Moritz,
Sorry for the late reply again. Travelling, and I'm now catching up.
Thanks again for your comments. And please do let us know what happens
with SLES11 when you get to it.
As for SLES10, I'll be adding to the 1.2 branch of the svn a comment above the
definition of readlink() in filewrappers.cpp :
// NOTE: If you see a compiler error: "declaration of C function ... conflicts
// with ... unistd.h", then consider changing READLINK_RET_TYPE in
// syscallwrappers.h. A user has reported this was needed for Linux SLES10.
If someone comes across this bug, the compiler error will direct them
to the line containing the definition of readlink() in filewrappers.cpp.
So, this comment should document what they need to do next.
I'm adding a similar comment in the svn trunk.
I'll be checking this in sometime in the next few days. So, it's still
easy to change the comment for greater clarity. (It's always good to have
two pairs of eyes look these things over.)
Best,
- Gene
On Thu, Jul 18, 2013 at 06:22:20PM +0000, Moritz Barsnick wrote:
Related
Bugs: #22