how to install xtables extension to arbitrary path?
Hi,
When building iptables, we can use "configure" to specify the xtables extension install path by "prefix" or "withxtlibdir". And when we running the iptables, iptables seems to search for the xtables extension libraries only in the path that was specified by "configure". If we move the xtables extension libraries to some other place, iptables will report failing to load the "so" files.
Because I'm doing cross compiling, and I will place the xtables extension libraries in the target board, and the final path might be different than the "configure" path. Do you know how to make iptables to load the correct xtables extensions?
Thanks.
Signature · 1 line
Xing Qianqian
Quoted 7 lines · Xing Qianqian
When building iptables, we can use "configure" to specify the xtables extension install path by "prefix" or "withxtlibdir". And when we running the iptables, iptables seems to search for the xtables extension libraries only in the path that was specified by "configure". If we move the xtables extension libraries to some other place, iptables will report failing to load the "so" files.
So don't move them ;-)
Quoted 3 lines
Because I'm doing cross compiling, and I will place the xtables extension libraries in the target board, and the final path might be different than the "configure" path.
You always have to specify final target-local paths to configure (in other words, as usual). This has never been different.
Quoted 2 lines
Do you know how to make iptables to
load the correct xtables extensions?
make install DESTDIR=/cross-chroot
Is what you need. This is used in about all the installation scripts in .spec files and similar in linux distributions' packages. Every automake-powered project has DESTDIR offered, it is not exactly a new thing.
Quoted 10 lines · Xing Qianqian <xingqq <at> 21com.com> writes:
Hi,
When building iptables, we can use "configure" to specify the xtables extension install path by "prefix" or "withxtlibdir". And when we running the iptables, iptables seems to search for the xtables extension libraries only in the path that was specified by "configure". If we move the xtables extension libraries to some other place, iptables will report failing to load the "so" files.
Quoted 7 lines
Because I'm doing cross compiling, and I will place the xtables extension libraries in the target board, and the final path might be different than the "configure" path. Do you know how to make iptables to load the correct xtables extensions?
Thanks.
Hi Xing,
I'm having the same issue. I'm able to cross compile but when I install to another file system the libraries always look at the absolute path which is not valid anymore. How did you get around the issue?
Quoted 13 lines
Quoted 13 lines
When building iptables, we can use "configure" to specify the xtables extension install path by "prefix" or "withxtlibdir". And when we running the iptables, iptables seems to search for the xtables extension libraries only in the path that was specified by "configure". If we move the xtables extension libraries to some other place, iptables will report failing to load the "so" files.
Because I'm doing cross compiling, and I will place the xtables extension libraries in the target board, and the final path might be different than the "configure" path. Do you know how to make iptables to load the correct xtables extensions?
Quoted 7 lines
Quoted 3 lines
Thanks.
Hi Xing,
I'm having the same issue. I'm able to cross compile but when I install to another file system the libraries always look at the absolute path which is not valid anymore. How did you get around the issue?
One possible solution to this (though not ideal by any means!) is to use modprobe and force the .so files to be loaded in advance as soon as the system is initialised (possibly through rc.sysinit). This is how I've got around the above problem as I also have a group of machines which use non-standard directories for xtables and ipset.
Quoted 8 lines · Mr Dash Four
Quoted 8 lines
Quoted 8 lines
When building iptables, we can use "configure" to specify the xtables extension install path by "prefix" or "withxtlibdir". And when we running the iptables, iptables seems to search for the xtables extension libraries only in the path that was specified by "configure". If we move the xtables extension libraries to some other place, iptables will report failing to load the "so" files.
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Because I'm doing cross compiling, and I will place the xtables extension libraries in the target board, and the final path might be different than the "configure" path. Do you know how to make iptables to load the correct xtables extensions?
Hi Xing,
I'm having the same issue. I'm able to cross compile but when I install to another file system the libraries always look at the absolute path which is not valid anymore. How did you get around the issue?
--prefix/--with-xtlibdir is only meant to specify the directory
relative to the root of the final running system. To stage files elsewhere, use the DESTDIR variable on make install. See autoconf info, section 16.4 "Installation names".
Quoted 3 lines
One possible solution to this (though not ideal by any means!) is to use modprobe and force the .so files to be loaded in advance as soon as the system is initialised (possibly through rc.sysinit).
Finding the .so files has nothing to do with modprobe however.
Quoted 3 lines
Finding the .so files has nothing to do with modprobe however.
Though it has everything to do with iptables finding and loading ipset/xtables .so libraries placed in non-standard directory however.
I'm using DESTDIR but it requires an absolute path which is only valid on the platform I compile. Suppose the DESTDIR is my NFS which is what my embedded platform uses, it will try to load the xtables libraries by using the absolute path from the install. This path is unknown from the embedded platform point of view.
Quoted 5 lines · Fabrice
I'm using DESTDIR but it requires an absolute path which is only valid on the platform I compile. Suppose the DESTDIR is my NFS which is what my embedded platform uses, it will try to load the xtables libraries by using the absolute path from the install. This path is unknown from the embedded platform point of view.
./configure --prefix=/usr make install DESTDIR=/srv/nfsroot
It can't be so hard to use that.
Quoted 9 lines · Jan Engelhardt <jengelh <at> medozas.de> writes:
Quoted 5 lines · Fabrice
I'm using DESTDIR but it requires an absolute path which is only valid on the platform I compile. Suppose the DESTDIR is my NFS which is what my embedded platform uses, it will try to load the xtables libraries by using the absolute path from the install. This path is unknown from the embedded platform point of view.
Quoted 4 lines
./configure --prefix=/usr make install DESTDIR=/srv/nfsrootIt can't be so hard to use that.
That is what I do and you are right it's not hard. The problem is on the embedded platform it will try to load the libs from /srv/nfsroot/ which is not valid. The absolute path is only valid on the platform where the install was done. I'm not sure if I explain the problem properly...I hope so...
Quoted 9 lines · Fabrice
Quoted 9 lines · Fabrice
Quoted 6 lines
I'm using DESTDIR but it requires an absolute path which is only valid on the platform I compile. Suppose the DESTDIR is my NFS which is what my embedded platform uses, it will try to load the xtables libraries by using the absolute path from the install. This path is unknown from the embedded platform point of view.
Quoted 7 lines
Quoted 4 lines
./configure --prefix=/usr make install DESTDIR=/srv/nfsrootIt can't be so hard to use that.
That is what I do and you are right it's not hard. The problem is on the embedded platform it will try to load the libs from
/srv/nfsroot/
It won't. It will load then from the prefix. Otherwise, a helluva lot Linux distros would have run into the problem already, because they use DESTDIR when making their packages.
Quoted 2 lines
which is not valid. The absolute path is only valid on the platform where the install was done. I'm not sure if I explain the problem properly...I hope so...
Quoted 5 lines
It won't. It will load then from the prefix. Otherwise, a helluva lot Linux distros would have run into the problem already, because they use DESTDIR when making their packages.
./configure --host=arm-linux --prefix=/usr
make
make DESTDIR=/home/workdir/filesys
ok here what I get when I install to the NFS:
# iptables -t nat -A POSTROUTING -o ppp0 -j SNAT -s 10.1.1.25 iptables v1.4.10: Couldn't load target `SNAT':/home/test/workdir/filesys/libexec/xtable s/libipt_SNAT.so: cannot open shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
It stills tries to load using the absolute path... I also noticed it did not add /usr to the path either...
I think I found the issue. It has to do with libtool when I make install. I saw this in the trace:
libtool: install: warning: relinking `libiptc/libiptc.la' /opt/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../ arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/lib" is unsafe for cross-compilation /opt/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../ arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc/opt/arm-2009q1/bin/../lib/gcc/ arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld:
skipping incompatible /usr/lib/libc.a when searching for -lc
libtool: install: warning: remember to run `libtool --finish /usr/lib'
libtool: install: warning: libiptc/libip4tc.la' has not been installed in /usr/lib'
libtool: install: warning: libiptc/libip6tc.la' has not been installed in /usr/lib'
So I did a make clean, configure and make. The I copied manually those libraries before the install to my NFS. It seems to work now :-)
Quoted 9 lines · Fabrice
I think I found the issue. It has to do with libtool when I make install. I saw this in the trace:
libtool: install: warning: relinking `libiptc/libiptc.la'/opt/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/lib" is unsafe for cross-compilation/opt/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible/usr/lib/libc.sowhen searching for -lc/opt/arm-2009q1/bin/../lib/gcc/
Please rerun with make V=1 so that I may see the libtool and ld command line that was used.
My guess is that something added -L/usr/lib to LDFLAGS, which of course is wrong since you would need -L/opt/arm-2009q1/lib .