Bug 244508 - sysutils/slurm-wlm: Fix build with clang 10.0.0
Summary: sysutils/slurm-wlm: Fix build with clang 10.0.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Jason W. Bacon
URL:
Keywords:
Depends on:
Blocks: 244251
  Show dependency treegraph
 
Reported: 2020-02-28 20:43 UTC by Dimitry Andric
Modified: 2020-03-15 01:37 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (jwb)


Attachments
Fix sysutils/slurm-wlm build with clang 10.0.0 (972 bytes, patch)
2020-02-28 20:43 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 2020-02-28 20:43:44 UTC
Created attachment 212032 [details]
Fix sysutils/slurm-wlm build with clang 10.0.0

As reported in bug 244251, with clang 10.0.0 the sysutils/slurm-wlm port fails to build with:

libtool: link: cc -O2 -pipe -I/wrkdirs/usr/ports/sysutils/slurm-wlm/work/slurm-19.05.5/slurm -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE -pthread -ggdb3 -Wall -g -O1 -fno-strict-aliasing -fstack-protector-strong -o .libs/sh5util sh5util.o -Wl,-rpath=/usr/local/lib/slurm -Wl,--export-dynamic  -L/usr/local/lib -L../../../../../src/api/.libs /wrkdirs/usr/ports/sysutils/slurm-wlm/work/slurm-19.05.5/src/api/.libs/libslurmfull.so ../.libs/libhdf5_api.a -lsysinfo -lkvm -lm -ldl -lz -lsz -lhdf5 -lhdf5_hl -pthread -Wl,-rpath -Wl,/usr/local/lib/slurm
ld: error: undefined symbol: info
>>> referenced by sh5util.c:210
>>>               sh5util.o:(main)
>>> referenced by sh5util.c:215
>>>               sh5util.o:(main)
>>> referenced by sh5util.c:220
>>>               sh5util.o:(main)
>>> referenced by sh5util.c:226
>>>               sh5util.o:(main)
>>> referenced by sh5util.c:653
>>>               sh5util.o:(_merge_step_files)
>>> referenced by sh5util.c:319
>>>               sh5util.o:(_remove_empty_output)

ld: error: undefined symbol: error
>>> referenced by sh5util.c:230
>>>               sh5util.o:(main)
>>> referenced by sh5util.c:0
>>>               sh5util.o:(_set_options)
>>> referenced by sh5util.c:0
>>>               sh5util.o:(_check_params)
>>> referenced by sh5util.c:599
>>>               sh5util.o:(_merge_step_files)
>>> referenced by sh5util.c:705
>>>               sh5util.o:(_merge_step_files)
>>> referenced by sh5util.c:718
>>>               sh5util.o:(_merge_step_files)
>>> referenced by sh5util.c:660
>>>               sh5util.o:(_merge_step_files)
>>> referenced by sh5util.c:667
>>>               sh5util.o:(_merge_step_files)
>>> referenced by sh5util.c:1148
>>>               sh5util.o:(_extract_series)
>>> referenced by sh5util.c:1155
>>>               sh5util.o:(_extract_series)
>>> referenced 21 more times
[... lots more of these...]

This is because libslurmfull.so is being linked using the following version script:

{ global: *;
  local: *;
};

It is ambiguous if it is meant that all the symbols should be global or local, and apparently lld 10 now chooses the latter.  Then of course none of the symbols such as info(), error() etc can be found.

This is easily fixed by removing the "local: *" line, by patching the Makefile.in that generates the version script.
Comment 1 Jason W. Bacon freebsd_committer 2020-03-07 17:25:53 UTC
I opened an issue with the SLURM developers to upstream a few patches including this one.

Awaiting feedback from them before committing the change.
Comment 2 commit-hook freebsd_committer 2020-03-15 01:34:36 UTC
A commit references this bug:

Author: jwb
Date: Sun Mar 15 01:34:01 UTC 2020
New revision: 528464
URL: https://svnweb.freebsd.org/changeset/ports/528464

Log:
  sysutils/slurm-wlm: Patch build system for clang/lld 10

  PR:             ports/244508
  Submitted by:   dim

Changes:
  head/sysutils/slurm-wlm/Makefile
  head/sysutils/slurm-wlm/files/patch-src_api_Makefile.in
Comment 3 Jason W. Bacon freebsd_committer 2020-03-15 01:37:28 UTC
No response from upstream yet besides acknowledgement of the patches, but a couple weeks of local testing haven't revealed any issues.  Thanks for the patch!