Re: error: only absolute run-paths are allowed

2018-04-02 Thread Bert Wesarg 
On Mon, Apr 2, 2018, 19:10 Jordy Dickinson <jordy.dickin...@icloud.com>
wrote:

> That is odd, but the file locally contains the value, which is
> "securelibdir"
>


than were is 'securelibdir' set?


> On Mon, 2018-04-02 at 17:07 +, Bert Wesarg wrote:
>
>
>
> On Mon, Apr 2, 2018, 18:42 Jordy Dickinson <jordy.dickin...@icloud.com>
> wrote:
>
> I'm trying to convert a PAM module's build system to an autotools
> project, and I'm having issues with libtool. The output of `make` is as
> follows:
>
> ```
> [...]
> /bin/sh ../../libtool  --tag=CC   --mode=link gcc  -g -O2 -module -no-
> undefined -avoid-version  -o pam_panic.la -rpath  pam_panic.lo
> pam_panic_authdevice.lo pam_panic_password.lo pam_panic_reject.lo
> libtool:   error: only absolute run-paths are allowed
> make[2]: *** [Makefile:449: pam_panic.la] Error 1
> make[2]: Leaving directory
> '/home/jordyd/Workspaces/pam_panic/src/pam_panic'
> make[1]: *** [Makefile:496: all-recursive] Error 1
> make[1]: Leaving directory
> '/home/jordyd/Workspaces/pam_panic/src/pam_panic'
> make: *** [Makefile:388: all-recursive] Error 1
> ```
>
> Here's my configure.ac:
>
> ```
> AC_INIT([pam_panic], [0.1.0], [], [pam_panic])
> AC_CONFIG_AUX_DIR([build-aux])
> AM_INIT_AUTOMAKE([-Wall])
> AC_PREREQ([2.69])
> AC_CONFIG_MACRO_DIR([m4])
> AC_CANONICAL_HOST
>
> AC_SUBST(PACKAGE)
> AC_SUBST(VERSION)
>
> AC_USE_SYSTEM_EXTENSIONS
> AC_PROG_CC
> AM_PROG_AR
>
> AC_PATH_PROG([REBOOT], [reboot])
> AC_SUBST(REBOOT)
> AC_PATH_PROG([POWEROFF], [poweroff])
> AC_SUBST(POWEROFF)
> AC_PATH_PROG([CRYPTSETUP], [cryptsetup])
> AC_SUBST(CRYPTSETUP)
>
> AC_ARG_ENABLE(securedir,
> AS_HELP_STRING([--enable-securedir=DIR],
> [path to location of PAMs @<:@default=$libdir/security@:>@]),
> SECUREDIR=$enableval, SECUREDIR=$libdir/security)
> AC_SUBST(SECUREDIR)
>
> LT_INIT([disable-static])
> AC_ENABLE_STATIC([no])
> AC_ENABLE_SHARED([yes])
>
> AC_CONFIG_FILES([
> Makefile
> src/pam_panic/config.h
> src/pam_panic/Makefile
> src/pam_panic/man/Makefile
> src/pam_panic_pw/config.h
> src/pam_panic_pw/Makefile
> src/pam_panic_pw/man/Makefile
> ])
>
> AC_OUTPUT
> ```
>
> Here's Makefile.am:
>
> ```
> ACLOCAL_AMFLAGS = -I m4
> CLEANFILES = *~
>
> SUBDIRS = src/pam_panic src/pam_panic_pw
> ```
>
> Finally, src/pam_panic/Makefile.am:
>
> ```
> SUBDIRS = man
>
> securelibexecdir = $()
>
>
> that looks odd, where is the value?
>
>
> securelibexec_LTLIBRARIES = pam_panic.la
> pam_panic_la_SOURCES = \
> pam_panic.c \
> pam_panic_authdevice.c \
> pam_panic_password.c \
> pam_panic_reject.c
> pam_panic_la_LDFLAGS = -module -no-undefined -avoid-version
> ```
>
> Any help would be appreciated.
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: error: only absolute run-paths are allowed

2018-04-02 Thread Bert Wesarg 
On Mon, Apr 2, 2018, 18:42 Jordy Dickinson 
wrote:

> I'm trying to convert a PAM module's build system to an autotools
> project, and I'm having issues with libtool. The output of `make` is as
> follows:
>
> ```
> [...]
> /bin/sh ../../libtool  --tag=CC   --mode=link gcc  -g -O2 -module -no-
> undefined -avoid-version  -o pam_panic.la -rpath  pam_panic.lo
> pam_panic_authdevice.lo pam_panic_password.lo pam_panic_reject.lo
> libtool:   error: only absolute run-paths are allowed
> make[2]: *** [Makefile:449: pam_panic.la] Error 1
> make[2]: Leaving directory
> '/home/jordyd/Workspaces/pam_panic/src/pam_panic'
> make[1]: *** [Makefile:496: all-recursive] Error 1
> make[1]: Leaving directory
> '/home/jordyd/Workspaces/pam_panic/src/pam_panic'
> make: *** [Makefile:388: all-recursive] Error 1
> ```
>
> Here's my configure.ac:
>
> ```
> AC_INIT([pam_panic], [0.1.0], [], [pam_panic])
> AC_CONFIG_AUX_DIR([build-aux])
> AM_INIT_AUTOMAKE([-Wall])
> AC_PREREQ([2.69])
> AC_CONFIG_MACRO_DIR([m4])
> AC_CANONICAL_HOST
>
> AC_SUBST(PACKAGE)
> AC_SUBST(VERSION)
>
> AC_USE_SYSTEM_EXTENSIONS
> AC_PROG_CC
> AM_PROG_AR
>
> AC_PATH_PROG([REBOOT], [reboot])
> AC_SUBST(REBOOT)
> AC_PATH_PROG([POWEROFF], [poweroff])
> AC_SUBST(POWEROFF)
> AC_PATH_PROG([CRYPTSETUP], [cryptsetup])
> AC_SUBST(CRYPTSETUP)
>
> AC_ARG_ENABLE(securedir,
> AS_HELP_STRING([--enable-securedir=DIR],
> [path to location of PAMs @<:@default=$libdir/security@:>@]),
> SECUREDIR=$enableval, SECUREDIR=$libdir/security)
> AC_SUBST(SECUREDIR)
>
> LT_INIT([disable-static])
> AC_ENABLE_STATIC([no])
> AC_ENABLE_SHARED([yes])
>
> AC_CONFIG_FILES([
> Makefile
> src/pam_panic/config.h
> src/pam_panic/Makefile
> src/pam_panic/man/Makefile
> src/pam_panic_pw/config.h
> src/pam_panic_pw/Makefile
> src/pam_panic_pw/man/Makefile
> ])
>
> AC_OUTPUT
> ```
>
> Here's Makefile.am:
>
> ```
> ACLOCAL_AMFLAGS = -I m4
> CLEANFILES = *~
>
> SUBDIRS = src/pam_panic src/pam_panic_pw
> ```
>
> Finally, src/pam_panic/Makefile.am:
>
> ```
> SUBDIRS = man
>
> securelibexecdir = $()
>

that looks odd, where is the value?


> securelibexec_LTLIBRARIES = pam_panic.la
> pam_panic_la_SOURCES = \
> pam_panic.c \
> pam_panic_authdevice.c \
> pam_panic_password.c \
> pam_panic_reject.c
> pam_panic_la_LDFLAGS = -module -no-undefined -avoid-version
> ```
>
> Any help would be appreciated.
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

[PATCH] Fix typo of non-existing function name

2016-06-13 Thread Bert Wesarg 

From fddcc0b117b5d4f3f4da95f183f19543354c39bb Mon Sep 17 00:00:00 2001
Message-Id: <fddcc0b117b5d4f3f4da95f183f19543354c39bb.1465850118.git.bert.wes...@googlemail.com>
From: Bert Wesarg <bert.wes...@googlemail.com>
Date: Mon, 13 Jun 2016 22:28:47 +0200
Subject: [PATCH] Fix typo of non-existing function name.

---
 build-aux/ltmain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 4cd3818..1cf2e7b 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -212,7 +212,7 @@ fi
 # a configuration failure hint, and exit.
 func_fatal_configuration ()
 {
-func__fatal_error ${1+"$@"} \
+func_fatal_error ${1+"$@"} \
   "See the $PACKAGE documentation for more information." \
   "Fatal configuration error."
 }
-- 
2.0.0.rc2.8.g2009c91

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

2015-02-11 Thread Bert Wesarg 
Robert,

On Wed, Feb 11, 2015 at 9:46 PM, Robert Boehne rboe...@gmail.com wrote:
 So if I read these correctly, you specify the runtime path with -R but not
 the link time location with -L ?

where did you get the impression, that I did not specify -L in
conjunction with -R? We obviously do this, because linking always
succeeds, but running the application not, because the runtime path is
missing.


 Does too run without help if you specify
 both when you build your Libtool library?

It is not about building libtool libraries, it is about linking
applications against libtool libraries, which depend on other
libraries which need rpath information.

Bert


 Robert Boehne

 On Feb 11, 2015 2:39 PM, Bert Wesarg bert.wes...@googlemail.com wrote:

 Hi,

 On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
 marcin.zalew...@gmail.com wrote:
  Hello.
 
  I have a contrib jemalloc library in my project that is not being
  built using libtool. When I build my libtool library, I add this to
  the link line:
 
  -ljemalloc -R/rpath/to/jemalloc
 
  This works fine, and my .la file includes:
 
  dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'
 
  However, when I link my programs with the .la file, I do not get rpath
  on the liker line, which causes a run-time failure when the program is
  run. Am I using the -R option correctly? I was hoping that I could
  make it a dependency in my .la file and not have to worry about it.
  The documentation for -R says:
 
  If output-file is a program, add libdir to its run-time path. If
  output-file is a library, add -Rlibdir to its dependency_libs, so
  that, whenever the library is linked into a program, libdir will be
  added to its run-time path.
 
  As far as I understood this, once my library has this dependency, the
  rpath will be added to any program that links to my library, but that
  is not happening.

 this is a known problem, though it seems that it is not considered as
 one by the libtool team:

 http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

 Bert

 
  Any help would be appreciated,
  -m

 ___
 https://lists.gnu.org/mailman/listinfo/libtool

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

2015-02-11 Thread Bert Wesarg 
Hi,

On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
marcin.zalew...@gmail.com wrote:
 Hello.

 I have a contrib jemalloc library in my project that is not being
 built using libtool. When I build my libtool library, I add this to
 the link line:

 -ljemalloc -R/rpath/to/jemalloc

 This works fine, and my .la file includes:

 dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'

 However, when I link my programs with the .la file, I do not get rpath
 on the liker line, which causes a run-time failure when the program is
 run. Am I using the -R option correctly? I was hoping that I could
 make it a dependency in my .la file and not have to worry about it.
 The documentation for -R says:

 If output-file is a program, add libdir to its run-time path. If
 output-file is a library, add -Rlibdir to its dependency_libs, so
 that, whenever the library is linked into a program, libdir will be
 added to its run-time path.

 As far as I understood this, once my library has this dependency, the
 rpath will be added to any program that links to my library, but that
 is not happening.

this is a known problem, though it seems that it is not considered as
one by the libtool team:

http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

Bert


 Any help would be appreciated,
 -m

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: inter-library-dependency, how?

2011-11-21 Thread Bert Wesarg 

Hi,



Hi Nick,

thanks for the quick response.

Am 09.09.2011 18:01, schrieb Nick Bowler:

On 2011-09-09 17:56 +0200, Christian Rössel wrote:

I want to build a program that depends on a libtool library that depends
on a non-libtool library that needs rpath information to be found a 
runtime.

My Makefile.am looks like this:
lib_LTLIBRARIES= libfoo.la
libfoo_la_SOURCES  = libfoo.c  libfoo.h
libfoo_la_CPPFLAGS = -I/opt/packages/papi/4.1.2.1/include
libfoo_la_LDFLAGS  = -L/opt/packages/papi/4.1.2.1/lib
libfoo_la_LIBADD   = -lpapi

bin_PROGRAMS = foo
foo_SOURCES  = foo.c
foo_LDADD= libfoo.la

[...]

Building and linking succeeds, but trying to run ./foo leads to
./foo: error while loading shared libraries: libpapi.so: cannot open
shared object file: No such file or directory

The library is in the location specified by libfoo_la_LDFLAGS (.a and
.so). But the rpath /opt/packages/papi/4.1.2.1/lib is not available. How
do I get it into foo without specifying it as
foo_LDFLAGS = -Wl,-rpath /opt/packages/papi/4.1.2.1/lib?

Looking at 
https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode,

   -R libdir
   If output-file is a program, add libdir to its run-time path. If
   output-file is a library, add -Rlibdir to its dependency_libs, so
   that, whenever the library is linked into a program, libdir will
   be added to its run-time path.

So it seems that adding -R/opt/packages/papi/4.1.2.1/lib to
libfoo_la_LDFLAGS would do the trick?

Well, like the documentations says, -R/opt/packages/papi/4.1.2.1/lib is
added to the dependency_libs:
dependency_libs=' -R/opt/packages/papi/4.1.2.1/lib
-L/opt/packages/papi/4.1.2.1/lib -lpapi'

But when I link libfoo.la into foo, nothing is added to foo's runpath:
libtool: link: gcc -g -O2 -o foo foo.o  ./.libs/libfoo.a
-L/opt/packages/papi/4.1.2.1/lib -lpapi

So, the problem remains. Any help appreciated.


Christian and I independently solved this with the following fix:

diff --git i/libltdl/config/ltmain.m4sh w/libltdl/config/ltmain.m4sh
index ca67c8a..f79ab5b 100644 libltdl/config/ltmain.m4sh
--- i/libltdl/config/ltmain.m4sh
+++ w/libltdl/config/ltmain.m4sh
@@ -6391,8 +6391,7 @@ func_mode_link ()
# Pragmatically, this seems to cause very few problems in
# practice:
case $deplib in
-   -L*) new_libs=$deplib $new_libs ;;
-   -R*) ;;
+   -L*|-R*) new_libs=$deplib $new_libs ;;
*)
  # And here is the reason: when a library appears more
  # than once as an explicit dependence of a library, or

With this patch, the -R flag inside the dependency_libs list is honored 
and appropriately added to the link command.


Is there anything wrong with this approach. If not we propose this patch 
for inclusion. A proper ChangeLog and Signed-of-by line will follow 
than. I will also try to transform Christians example into an test than.


Thanks.

Bert



Thanks,



___
https://lists.gnu.org/mailman/listinfo/libtool

Re: inter-library-dependency, how?

2011-11-21 Thread Bert Wesarg 
On Mon, Nov 21, 2011 at 16:31, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
 On Mon, 21 Nov 2011, Bert Wesarg wrote:

 Christian and I independently solved this with the following fix:

 diff --git i/libltdl/config/ltmain.m4sh w/libltdl/config/ltmain.m4sh
 index ca67c8a..f79ab5b 100644 libltdl/config/ltmain.m4sh
 --- i/libltdl/config/ltmain.m4sh
 +++ w/libltdl/config/ltmain.m4sh
 @@ -6391,8 +6391,7 @@ func_mode_link ()
           # Pragmatically, this seems to cause very few problems in
           # practice:
           case $deplib in
 -           -L*) new_libs=$deplib $new_libs ;;
 -           -R*) ;;
 +           -L*|-R*) new_libs=$deplib $new_libs ;;
           *)
             # And here is the reason: when a library appears more
             # than once as an explicit dependence of a library, or

 With this patch, the -R flag inside the dependency_libs list is honored
 and appropriately added to the link command.

 Is there anything wrong with this approach. If not we propose this patch
 for inclusion. A proper ChangeLog and Signed-of-by line will follow than. I
 will also try to transform Christians example into an test than.

 Yes, I think that there is something wrong with this approach.  The -R
 option should not be used to find libraries at link time.  Libraries present
 in the run-time linker search path at link time are not necessarily the
 correct ones to be used for linking.  Run-time linker search path and
 link-time linker search path are totally different things.

The -R option is not used by libtool to find libraries at link-time,
it tells libtool to add this path to the targets run-time linker
search path. I.e. it passes -Wl,-rpath -Wl,path to the linker.

Thus, this patch does what the documentation says:

https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode

Bert


 Bob

___
https://lists.gnu.org/mailman/listinfo/libtool