Project

General

Profile

Bug #304

some libraries are only built statically, preventing a Charm++ installation with only dynamic libraries

Added by Nicolas Bock almost 6 years ago. Updated about 4 years ago.

Status:
Merged
Priority:
High
Assignee:
Category:
-
Target version:
Start date:
10/11/2013
Due date:
% Done:

0%


Description

I package Charm++ for Gentoo Linux, but the same should be true for other Linux distributions:

On a typical Linux system only shared libraries are installed, because of the usual security and bloat arguments. However, if I build charm with --build-shared, and then install only what is in lib_so, the charmc script breaks because some Converse libraries are built purely as .o and don't end up in lib_so. One example is seed based load balancing, e.g. libldb-rand.o. As far as I can tell, this is not too hard to fix. In the main makefile, the targets libldb-*.o are renamed to libldb-*.a, and the charmc script now tests both .a and .so when linking the seed based load balancing code.

I have attached a patch against charm/HEAD.

0001-Some-libraries-are-only-built-statically.patch View (3.75 KB) Nicolas Bock, 10/11/2013 05:48 PM

0001-Some-libraries-are-only-built-statically.patch View (17.1 KB) Nicolas Bock, 10/14/2013 04:11 PM

0001-Some-libraries-are-only-built-statically.patch View (17 KB) Nicolas Bock, 10/14/2013 11:28 PM


Related issues

Related to Charm++ - Bug #825: Link time error for Neighbor LB Merged 09/02/2015

History

#1 Updated by Phil Miller almost 6 years ago

  • Assignee set to Phil Miller
  • Target version set to 6.6.0

This mostly looks good. One question on the change to charmc. Should the first condition and associated then branch refer to libldb-$BALANCE.a as it's now being built, rather than the current libldb-$BALANCE.o?

#2 Updated by Nicolas Bock almost 6 years ago

Yes, you are right, I missed that one. I have worked on the patch a bit more and attached the new version. I had to also change the linker order a bit because changing something like libldb-*.o -> libldb-*.a means that the library has to come after libck. Please have another critical look. Thanks.

#3 Updated by Phil Miller almost 6 years ago

That looks like it solves the issue I pointed out.

Could you abstract the repeated $CHARMLIB/libfoo.a|$CHARMLIBSO/libfoo.so selection logic into a standalone function?

#4 Updated by Nicolas Bock almost 6 years ago

What do you think of this?

As an aside, I noticed that the parallel build breaks now when using --build-shared at the point the makefile is trying to build the libmemory-*.{a,so} modules. I think it's because the modules all come from the same source file, memory.c, and the intermediate, memory.o, goes missing or is overwritten when several threads are building different modules.

#5 Updated by Phil Miller over 5 years ago

There's a makefile trick to avoid the trouble that both multiple targets from a source and parallel builds encounter here, but it looks a bit hackish to the uninitiated - I half scared a professor in undergrad using it on an assignment. Essentially, for each target, the makefile needs to create a corresponding named symlink to the source file, so that any intermediate object files get the unique target's name and not the common source file's name. I'll look at implementing that here, though it may run into trouble on our Windows builds, where symlinks are faked.

#6 Updated by Nicolas Bock over 5 years ago

I don't quite understand why symlinking helps. Why not create a temporary name and then run the compiler with "-c -o TEMPNAME.o"? Wouldn't that solve this problem?

#7 Updated by Phil Miller over 5 years ago

  • Target version changed from 6.6.0 to 6.7.0

Deferring to after the 6.6 release, because I'm not quite ready to deal with the changes necessary to preserve parallel compilation.

#8 Updated by Nicolas Bock over 5 years ago

What about copying the files instead of symlinking in the makefile to avoid problems on Windows (or simply stop supporting Windows ;-) )? If you think that's a good idea, I'll have a go at an updated patch...

#9 Updated by Phil Miller over 4 years ago

  • Status changed from New to Implemented

Changes to be pushed shortly.

#10 Updated by Phil Miller over 4 years ago

Pushed here, waiting for Nikhil's assistance in dealing with mpi-mainmodule.o: http://charm.cs.uiuc.edu/gerrit/#/c/465/

#11 Updated by Phil Miller over 4 years ago

  • Priority changed from Normal to High

#12 Updated by Phil Miller about 4 years ago

  • Status changed from Implemented to Merged

I was dumb, and didn't notice that Nikhil had answered my request within a few hours. This could have been merged months ago.

Also available in: Atom PDF