dlopen() libcr.so, and problem with C++ compilers?

From: Alan Woodland (alan.woodland_at_gmail_dot_com)
Date: Fri Feb 13 2009 - 08:05:24 PST

  • Next message: Paul H. Hargrove: "Re: dlopen() libcr.so, and problem with C++ compilers?"
    I've been working on using BLCR with my application, and I've
    encountered a few issues:
    I've been trying to integrate BLCR into one of my applications such
    that it will transparently work provided the machine the application
    is running on has the BLCR library and kernel modules available.
    I was under the impression from the documentation that a sensible way
    to make this work on both machines with and without BLCR was to use
    dlopen()/dlsym() at run time, but the problem is that
    cr_initialize_restart_args_t and cr_initialize_checkpoint_args_t are
    both macros, which means they're not symbols in libcr.so - my only
    options are to use the private interfaces they call (nasty) or link at
    compile time here.
    Any suggestions for a better work-around than using the private
    interfaces? It makes the software engineer in me die a little to do
    This one's quite minor - I should really just use a C compiler instead
    I guess...
    The macro  CR_RSTRT_RELOCATE_SIZE(CR_MAX_RSTRT_RELOC) has made life in
    C++ harder. It evaluates to:
    (sizeof(struct cr
    _rstrt_relocate) + (16) * sizeof(struct cr_rstrt_relocate_pair))
    But I think in C++ this is one of those subtle C/C++ differences. In
    C++ I think it needs to be
    (sizeof(struct cr_rstrt_relocate) + (CR_MAX_RSTRT_RELOC *
    sizeof(cr_rstrt_relocate::cr_rstrt_relocate_pair))) works instead.
    If cr_rstrt_relocate_pair were defined and declared outside of
    cr_rstrt_relocate that would work for both C and C++ with the current
    macro? Or a #ifdef __CPLUSPLUS for two versions of that macro?
    Is it safe to write things into the file before the checkpoint itself?
    I want to write information about relocations that will be needed by
    my application into the same file. It seems to be working, but would
    it be better being written after? Could it ever seek to the beginning
    of a file explicitly during loading? Or will it always just start from
    where the file was when it was given it? Does it ignore extra bits at
    the end of a file? It seems to work fine with extra info at the
    beginning of the file provided I make the seek on the file handle to
    the appropriate point first. Is this 'as designed' and guaranteed to
    work with future versions?

  • Next message: Paul H. Hargrove: "Re: dlopen() libcr.so, and problem with C++ compilers?"