Please use *_LIBADD automake variable for adding liibraries and *_LDFALGS for using other linked flags.

This is an example for different project :-)

libipa_hbac_la_LIBADD = \
    $(UNICODE_LIBS)
libipa_hbac_la_LDFLAGS = \
    -Wl,--version-script,$(srcdir)/src/lib/ipa_hbac/ipa_hbac.exports \
    -version-info 1:0:1

BTW you probably know that but if you add libraries to binary instead of binary then you use $(binary_name)_LDADD instead of $(binary_name)_LIBADD

It would be also good to mention what kink of stricter linking was changed on rawhide. Hint: -Wl,-z,defs. So basically anybody can test even on debian,f27

Anyway, patch fixes building with -Wl,-z,defs
I used following line for configure:

./configure --with-selinux --with-systemd --enable-cmocka 'LDFLAGS=-Wl,-z,defs'

And after checking usage of *_LIBADD, *_LDFLAGS and AM_LDFLAGS it would take some time to have it in recommended autotools way.

ACK but it would be good to mention -Wl,-z,defs in commit message before pushing the patch.

And after checking usage of _LIBADD, _LDFLAGS and AM_LDFLAGS it would take some time to have it in recommended autotools way.
ACK but it would be good to mention -Wl,-z,defs in commit message before pushing the patch.

Will do, thanks Lukas!

Thanks for the review!

cb7bda3..f95b8e7 master -> master

Okay, so the one change made in the last patch to fix the build is now all of sudden breaking the build on f28/f29:

+libldaputil_la_LIBADD = libslapd.la  $(NSS_LINK) $(NSPR_LINK)

When I change it to this is fixes the builds again

+libldaputil_la_LIBADD =  $(NSS_LINK) $(NSPR_LINK)

This change makes sense because libldaputiul and libslapd are completely unrelated, but I don't recall why I "needed" to make change the first time :-/ Perhaps gcc was in an unstable state at the time I first found the problem. Who knows.

b05fe2f..2020610 master -> master

FYI "-Wl,-z,defs" was removed form fedora standard linker flags provided by redhat-rpm-config. You can still enable it in spec file with defining rpm macro
%define _strict_symbol_defs_build 1

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#strict-symbol-checks-in-the-link-editor-ld

FYI "-Wl,-z,defs" was removed form fedora standard linker flags provided by redhat-rpm-config. You can still enable it in spec file with defining rpm macro
%define _strict_symbol_defs_build 1
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#strict-symbol-checks-in-the-link-editor-ld

I'll add that to the specfile when I do the next build. I actually almost contacted you about this, I was having a really hard time figuring out why the builds were suddenly failing. Total wack-a-mole, but I figured it out eventually.

Thanks
Mark

Ugh still having problems. Looks like libldaputiul.la does need libslapd.la after all. Getting different build results on different platforms on f28

[mareynol@localhost 389-ds-base]$ cd lib/ldaputil/
[mareynol@localhost ldaputil]$ grep -r slap
cert.c:#include "slapi-plugin.h"
cert.c: slapi_ldap_value_free(rdn);
cert.c: auto char rdns = slapi_ldap_explode_dn(dn, 0);
cert.c: auto char avas = slapi_ldap_explode_rdn(*rdn, 0);
cert.c: slapi_ldap_value_free(avas);
cert.c: slapi_ldap_value_free(avas);
cert.c: slapi_ldap_value_free(rdns);
init.c:#include "slapi-plugin.h"
ldapauth.c:#include "slapi-plugin.h"
ldapauth.c: num_namingcontexts = slapi_ldap_count_values(suffix);

I'm really not sure what is going on. Continuing investigation...

The problem is related to the Makefile changes that were added when we absorbed the svrcore package into DS.

The last commit definitely needs to be undone, and we need to properly fix Makefile.am in regards to "svrcore"

Reverted the change around adding libslapd.la to libldaputil

dbc4a24..ab35fe8 master -> master

Thanks @mhonek

ab35fe8..c1d38ca master -> master

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2611

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.