>>>>> "Danny" == Danny Auble <[email protected]> writes:

Hi Danny,

thanks for your fast reply.

    Danny> Hi Roland, We found this to be the only generic way of
    Danny> handling things.  On some architectures not all symbols would
    Danny> be visible from the common area in the plugins when doing a
    Danny> dynamic link.  This was not the case for a regular linux
    Danny> cluster like yours but it is not a silver bullet.

    Danny> We are aware it is not ideal, but on some systems it didn't
    Danny> appear there was any other way of doing it.

would probably have to be made configurable.

    Danny> Sorry for the inconvenience.  If you want to change the code
    Danny> as you describe you are welcome to it as it should work on
    Danny> your system, but probably won't in every case.

Hmm, this doesn't seem to be as straightforward as hoped. Just linking
against libslurm.so is not the same as adding libslurm.o to the link
line. I also need code from libeio.o libspank.o libcommon.o, and these
are not built as a shared lib. If I link in the static version of these
convenience libs together with libslurm.so, the executable is even
larger than just adding libslurm.o. Seems building against shared libs
is not supported unfortunately, or am I missing something? I'm asking
myself, what is the real value of having libslurm.so and libslurmdb.so
then.

Roland


    Danny> Danny

    >> Hi,
    >> 
    >> I noticed that when building slurm (2.2.5 on Ubuntu amd64
    >> 10.04.1), all utilities are built with (example snippet from
    >> sacct Makefile.am):
    >> 
    >> sacct_LDADD = $(top_builddir)/src/db_api/libslurmdb.o -ldl
    >> 
    >> instead of linking against libslurm.so. Is linking against
    >> libslurm.so not supported currently, or what is the reason for
    >> this. It makes the whole package use more than 25 times the space
    >> it would really need to.
    >> 
    >> Thanks,
    >> 
    >> Roland
    >> 

Reply via email to