Skip to content

Commit

Permalink
tests: use RUNPATH instead of RPATH consistently (#309)
Browse files Browse the repository at this point in the history
some vendors default to RPATH, others to RUNPATH. The former does not allow override
with LD_LIBRARY_PATH when running binaries such as test suite and it was causing
problems on platforms where RPATH is default, by running the test suite against
the wrong library (out-of-tree vs in-tree).

This change has no effect on libqb itself, but only on the binaries.

Signed-off-by: Fabio M. Di Nitto <[email protected]>
  • Loading branch information
fabbione authored and chrissie-c committed May 3, 2018
1 parent 0ec02f9 commit eeb5e45
Show file tree
Hide file tree
Showing 2 changed files with 84 additions and 0 deletions.
10 changes: 10 additions & 0 deletions configure.ac
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,17 @@ dnl command line
dnl Wrap in m4_ifdef to avoid breaking on older platforms
m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
LT_PREREQ([2.2.6])
# --enable-new-dtags: Use RUNPATH instead of RPATH.
# It is necessary to have this done before libtool does linker detection.
# See also: https://github.com/kronosnet/kronosnet/issues/107
AX_CHECK_LINK_FLAG([-Wl,--enable-new-dtags],
[AM_LDFLAGS=-Wl,--enable-new-dtags],
[AC_MSG_ERROR(["Linker support for --enable-new-dtags is required"])])
AC_SUBST([AM_LDFLAGS])
saved_LDFLAGS="$LDFLAGS"
LDFLAGS="$AM_LDFLAGS $LDFLAGS"
LT_INIT
LDFLAGS="$saved_LDFLAGS"

AC_CONFIG_MACRO_DIR([m4])

Expand Down
74 changes: 74 additions & 0 deletions m4/ax_check_link_flag.m4
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
# ===========================================================================
# https://www.gnu.org/software/autoconf-archive/ax_check_link_flag.html
# ===========================================================================
#
# SYNOPSIS
#
# AX_CHECK_LINK_FLAG(FLAG, [ACTION-SUCCESS], [ACTION-FAILURE], [EXTRA-FLAGS], [INPUT])
#
# DESCRIPTION
#
# Check whether the given FLAG works with the linker or gives an error.
# (Warnings, however, are ignored)
#
# ACTION-SUCCESS/ACTION-FAILURE are shell commands to execute on
# success/failure.
#
# If EXTRA-FLAGS is defined, it is added to the linker's default flags
# when the check is done. The check is thus made with the flags: "LDFLAGS
# EXTRA-FLAGS FLAG". This can for example be used to force the linker to
# issue an error when a bad flag is given.
#
# INPUT gives an alternative input source to AC_LINK_IFELSE.
#
# NOTE: Implementation based on AX_CFLAGS_GCC_OPTION. Please keep this
# macro in sync with AX_CHECK_{PREPROC,COMPILE}_FLAG.
#
# LICENSE
#
# Copyright (c) 2008 Guido U. Draheim <[email protected]>
# Copyright (c) 2011 Maarten Bosmans <[email protected]>
#
# This program is free software: you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 3 of the License, or (at your
# option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
# Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program. If not, see <https://www.gnu.org/licenses/>.
#
# As a special exception, the respective Autoconf Macro's copyright owner
# gives unlimited permission to copy, distribute and modify the configure
# scripts that are the output of Autoconf when processing the Macro. You
# need not follow the terms of the GNU General Public License when using
# or distributing such scripts, even though portions of the text of the
# Macro appear in them. The GNU General Public License (GPL) does govern
# all other use of the material that constitutes the Autoconf Macro.
#
# This special exception to the GPL applies to versions of the Autoconf
# Macro released by the Autoconf Archive. When you make and distribute a
# modified version of the Autoconf Macro, you may extend this special
# exception to the GPL to apply to your modified version as well.

#serial 5

AC_DEFUN([AX_CHECK_LINK_FLAG],
[AC_PREREQ(2.64)dnl for _AC_LANG_PREFIX and AS_VAR_IF

This comment has been minimized.

Copy link
@bubble75

bubble75 Jun 4, 2018

This breaks build on EL6

This comment has been minimized.

Copy link
@fabbione

fabbione Jun 4, 2018

Author Member

do you have logs handy? I can look at it in a couple of days, but libqb/master is not a target for el6 at the moment.

This comment has been minimized.

Copy link
@fabbione

fabbione Jun 4, 2018

Author Member

ok I see the problem, I´ll defer to @chrissie-c if we plan to support el6 with newer versions of libqb or not.

tl;dr @chrissie-c the version of autoconf required for this macro to work is too new vs what is available in el6, we could potentially force RUN_PATH in other ways, but detection is better.

AS_VAR_PUSHDEF([CACHEVAR],[ax_cv_check_ldflags_$4_$1])dnl
AC_CACHE_CHECK([whether the linker accepts $1], CACHEVAR, [
ax_check_save_flags=$LDFLAGS
LDFLAGS="$LDFLAGS $4 $1"
AC_LINK_IFELSE([m4_default([$5],[AC_LANG_PROGRAM()])],
[AS_VAR_SET(CACHEVAR,[yes])],
[AS_VAR_SET(CACHEVAR,[no])])
LDFLAGS=$ax_check_save_flags])
AS_VAR_IF(CACHEVAR,yes,
[m4_default([$2], :)],
[m4_default([$3], :)])
AS_VAR_POPDEF([CACHEVAR])dnl
])dnl AX_CHECK_LINK_FLAGS

7 comments on commit eeb5e45

@chrissie-c
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no plans to support libqb on EL6 as nothing we have on that platform needs it. I'll take patches if other people feel the need though ;-)

@bubble75
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it seems like linker script does not work on EL6 as well. I'll look for direct linking to not break logging, and if it breaks, then it is probably a good reason to move to EL7.

@chrissie-c
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't surprise me either, sadly. The linking for libqb is waaayy over-complicated!

@fabbione
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's important to understand what is the use case for having latest and greatest libqb on EL6. I mean if there are many applications out there using it, then it might make sense to figure out a way to support EL6, but otherwise moving to EL7+ is the way to go.

@bubble75
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a wanting of having latest cluster stack on EL6 to postpone the "big move".

@chrissie-c
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are literally no applications for libqb in EL6 - it doesn't even exist there :) Trying to put the new cluster stack on it sounds like almost as big a job as upgrading to EL7 really.

@bubble75
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, but that was done a long ago, so almost no new efforts (except that libqb/ld issue) to support that. Moving to EL7 for me is a complete rewrite of the whole cluster boot paradigm (PXE-booted with ISO-root and network state space) and that requires a lot of work. I understand that I will need to that once anyways, just wanted to postpone that as long as possible ;)

Please sign in to comment.