Linking issues about apbs

[sobolevnrm]

Hello; thank you for reporting this. I'm adding @intendo for his help. Thank you.

[intendo]

@dvdesolve can you tell us:

• what version of CMake
• which compiler (gcc/g++) and what version

Have you tried downloading the binaries at https://sourceforge.net/projects/apbs/files/apbs/apbs-3.0/APBS-3.0.0_Linux.zip/download to see if they will work on Arch Linux?

[dvdesolve]

GCC version is 10.1 and CMake is 3.18.1.
Binary version actually can't be installed and run because it doesn't include full set of libraries needed for apbs to work. This is the main reason why I want to compile from source.

[intendo]

I have a similar problem with GCC 10.2. I had to go back to GCC 9.3 to get APBS to compile.
APBS has several external source code projects. You may want to try turning all the options off in your CMake command. If that works, you can enable 1 of them and see if that works. That is how I eventually got all of them to compile. Some of the external git submodules don't work on systems like Windows 10 or MacOS. We are in the process of trying to update the APBS code base to use more Python and less of the external dependencies to simplify maintenance and improve overall quality.

[dvdesolve]

Actually it seems like the problem isn't compiler-related.

Each of source files:

• src/pmgc/gsd.c
• src/pmgc/matvecd.c
• src/pmgc/mgcsd.c
• src/pmgc/mgdrvd.c
• src/pmgc/mgfasd.c
• src/pmgc/mgsubd.c
• src/pmgc/mypdec.c
• src/pmgc/newdrvd.c
• src/pmgc/newtond.c
• src/pmgc/powerd.c
• src/pmgc/smoothd.c
  include src/pmgc/mypdec.h (directly or via include header tree) which contains the following lines:

/// @todo  Remove dependencies on global variables
double v1, v2, v3, conc1, conc2, conc3, vol, relSize;
int nion;
double charge[MAXIONS];
double sconc[MAXIONS];

Instead of declaration of offending variables it defines them. So each source file targeting this header as a result defines its own global variable and that leads to the linking errors.

Moreover the following files:

• src/pmgc/mgdrvd.c
• src/pmgc/mgfasd.c
• src/pmgc/mgsubd.c
• src/pmgc/newdrvd.c
• src/pmgc/newtond.
• src/pmgc/powerd.c
  include src/pmgc/mgsubd.h (directly or not) and it contains the following:

/// @todo  Get rid of these globals in refactor
double bf, oh, cputme;

The problem here is the same as with src/pmgc/mypdec.h.

Files src/pmgc/cgd.c and/or src/pmgc/mgcsd.c also include offending headers so we have these linking errors.

One possible fix for that problem is:

--- src/pmgc/mgsubd.c	2020-08-17 22:19:58.337848512 +0300
+++ src/pmgc/mgsubd.c	2020-08-17 22:52:50.806919186 +0300
@@ -52,10 +52,12 @@
  * @endverbatim
  */
 
 #include "mgsubd.h"
 
+double bf, oh, cputme;
+
 VPUBLIC void Vbuildops(
         int *nx, int *ny, int *nz,
         int *nlev, int *ipkey, int *iinfo,
         int *ido, int *iz,
         int *mgprol, int *mgcoar, int *mgsolv, int *mgdisc, int *ipc,
--- src/pmgc/mgsubd.h	2020-08-17 22:19:58.337848512 +0300
+++ src/pmgc/mgsubd.h	2020-08-17 22:52:44.133442142 +0300
@@ -253,11 +253,11 @@
         int n3  ///< The third grid size
         );
 
 
 /// @todo  Get rid of these globals in refactor
-double bf, oh, cputme;
+extern double bf, oh, cputme;
 
 /** @brief   This routine prints out some info and such from inside multigrid.
  *  @author  Tucker Beck [C Translation], Michael Holst [Original]
  *  @note    Replaces prtstp from mgsubd.f
  */
--- src/pmgc/mypdec.c	2020-08-17 22:19:58.337848512 +0300
+++ src/pmgc/mypdec.c	2020-08-17 22:51:45.158838887 +0300
@@ -52,10 +52,15 @@
  * @endverbatim
  */
 
 #include "mypdec.h"
 
+double v1, v2, v3, conc1, conc2, conc3, vol, relSize;
+int nion;
+double charge[MAXIONS];
+double sconc[MAXIONS];
+
 VPUBLIC void Vmypdefinitlpbe(int *tnion, double *tcharge, double *tsconc) {
 
     int i;
 
     nion = *tnion;
--- src/pmgc/mypdec.h	2020-08-17 22:19:58.337848512 +0300
+++ src/pmgc/mypdec.h	2020-08-17 22:51:33.588589765 +0300
@@ -65,14 +65,14 @@
 #define ZLARGE     1.0e20
 #define SINH_MIN -85.0
 #define SINH_MAX  85.0
 
 /// @todo  Remove dependencies on global variables
-double v1, v2, v3, conc1, conc2, conc3, vol, relSize;
-int nion;
-double charge[MAXIONS];
-double sconc[MAXIONS];
+extern double v1, v2, v3, conc1, conc2, conc3, vol, relSize;
+extern int nion;
+extern double charge[MAXIONS];
+extern double sconc[MAXIONS];
 
 #define Na 6.022045000e-04
 
 /** @brief   Set up the ionic species to be used in later calculations.  This
  *           must be called before any other of the routines in this file.

[lwwilson1]

@dvdesolve was helpful enough to point out this issue and investigate it in TABI-PB as well; it looks like it's because gcc 10 is finally enforcing no common blocks as a default. It looks like you can also work around it by compiling with -fcommon when using gcc-10, but that's probably the last-place solution to the problem.

[dvdesolve]

After applying my patch for global variables I've faced another problem with linking of libmaloc.so. During building the following error occurs:

Scanning dependencies of target mgmesh
[ 79%] Building C object tools/mesh/CMakeFiles/mgmesh.dir/mgmesh.c.o
[ 79%] Linking C executable ../bin/mgmesh
/usr/bin/ld: /opt/buildcache/makepkg/apbs/src/apbs-3.0.0/apbs/build/fetk/lib/libmaloc.so: undefined reference to «pow»

I've tried to add linking with libm.so explicitly both in apbs/tools/mesh/CMakeLists.txt and in apbs/externals/fetk/maloc/src/CMakeLists.txt via target_link_libraries() but it doesn't work. Seems like FETk is built by APBS without CMake but with old AutoTools approach. I don't know what to do in such situation.

[intendo]

I think the linking issue may be a race condition between CMake, autoconf, downloading files, and make running in parallel. I have run into this before and it is not consistent.

Instead of just typing make which will default to running a few of the autoconf steps in parallel, try using VERBOSE=1 make -j 1 which forces all the compiling to be done in serial and eliminates any race condition. There should be a .build.sh file which is what I use to build, test, and bundle APBS using Github actions.

Let us know if that works.

[dvdesolve]

Actually it looks like the problem with undefined reference to pow isn't related to the race condition during make. I've tried to build from pure source with serial make and all worked just fine. However when I've tried to build with makepkg utility (this is Arch Linux way to build packages) then I've got the same error despite of serialized make run.

The only difference between two ways is that makepkg utility exports some compilation and linking flags defined in /etc/makepkg.conf on Arch systems. When I've turned off these flags in my PKGBUILD script compilation went just fine. So I'm pretty sure that system-wide compilation flags interfere with building process (the same should be the case for all Linux distribs that export these flags such as Gentoo).

If you're curious about them here are the list (CMake should ignore CPPFLAGS, though):

CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

I think because we're getting troubles during linking LDFLAGS may be the offending ones.

[dvdesolve]

I've updated Arch Linux package so it can be built now with full support of 3rd party tools/utils. I've attached two patches inside it as a temporary solution. We'll get rid of them when new version out.

Can you please add link to it in docs?

[sobolevnrm]

Thank you! I'll work on this.