bug-gnu-libiconv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gnu-libiconv] rpath still set by libtool for iconv build even with


From: Fred Heinecke
Subject: [bug-gnu-libiconv] rpath still set by libtool for iconv build even with disable-rpath configuration flag is set
Date: Mon, 13 Nov 2023 10:46:48 +0000 (UTC)

Hi folks,

I think I found a bug with the build process for the iconv executable. It 
appears that regardless of whether or not the "--disable-rpath" flag is set, 
the lib directory is still set by libtool upon "make install". Below is a 
couple of end to end examples on how to reproduce this:

#!/bin/bash

OUTPUT_DIR=/tmp/build_output
mkdir -p "$OUTPUT_DIR"

git clone git://git.savannah.gnu.org/libiconv.git
cd libiconv
git checkout 317dfadc6c68b3465205873b140200e5b0d0256f
./autopull.sh
./autogen.sh

# This is ran before each example to clean up the previous example
# make distclean
# rm -r "${OUTPUT_DIR:?}/"*

# Example 1
./configure
DESTDIR="$OUTPUT_DIR" make install
strings /tmp/build_output/usr/local/bin/iconv | grep "/tmp/build_output"    # 
This shows "/tmp/build_output/usr/local/lib"

# Example 2
./configure --disable-rpath
DESTDIR="$OUTPUT_DIR" make install
strings /tmp/build_output/usr/local/bin/iconv | grep "/tmp/build_output"    # 
This shows "/tmp/build_output/usr/local/lib"

# End script

I have a more complex build example that I can share as well where the path 
string listed here repeats the output lib directory path twice 
("/tmp/build_output/usr/local/lib:/tmp/build_output/usr/local/lib"), but I'm 
having some trouble getting this down to something simple. I can share it if 
requested, but it involves cross compiling the project for another filesystem 
with a LLVM toolchain.

Any idea if this is actually a bug, or if I am naively missing a configuration 
flag/makefile var?

Thanks,

Fred

P.S. The "bug-gnu-libiconv-antispam@gnu.org" address listed as the "mailto" 
target under the bug report section on https://www.gnu.org/software/libiconv/ 
is not routable by my email provider (Yahoo). I'm guessing this is intentional 
given the name, but if so it is inconsistent with the mailing list page at 
https://lists.gnu.org/mailman/listinfo/bug-gnu-libiconv.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]