quantum / esos

An open source, high performance, block-level storage platform.
http://www.esos-project.com/
Other
284 stars 58 forks source link

Can't find libwrap.so #46

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Download r571 source, unpack it, autoconf
2. add path to /usr/include in CPPFLAGS of Makefile.in.
3. (optional, you may have it in your environment) install tcp_wrapper, 
tcp_wrapper-devel and tcp_wrapper-libs
4. configure; make; make image; install.sh
5. boot a storage server with newly created usb key, when you try to configure 
the network, the error
  message will appear because libwrap.so which belongs to tcp_wrapper-libs is not included in the system.

What is the expected output? What do you see instead?
no such error message should appear.

What version of the product are you using? On what operating system?
esos 0.1-r571 / CentOS 6.4 x86_64

Please provide any additional information below.
The issue is caused by the fact that the package tcp_wrapper-libs for CentOS 
(RHEL etc.) doesn't include a static version of the library, when compiling 
nrpe, the dynamic library, libwrap.so in my compiling machine  was linked. ESOS 
itself doesn't include tcp_wrapper, so the issue occurs.

My question:
Should I compile a static libwrap.a in my compiling machine and force nrpe to 
link the static version?
Or, ESOS need to include tcp_wrapper?

Original issue reported on code.google.com by hqz...@nju.edu.cn on 9 Feb 2014 at 5:15

GoogleCodeExporter commented 9 years ago
I have checked the SPEC file created by Redhat for building tcp_wrappers-7.6-57 
package, it seems that the static library libwrap.a was removed on purpose 
since version 7.6-42.1.

--snippet of the SPEC file--
* Thu Mar 08 2007 Tomas Janousek <tjanouse@redhat.com> - 7.6-42.1
- moved libwrap.so* to /lib
- removed the static library libwrap.a 

Original comment by hqz...@nju.edu.cn on 10 Feb 2014 at 6:24

GoogleCodeExporter commented 9 years ago
Hi,

Why are you modifying CPPFLAGS in Makefile.in? Adding non-ESOS includes would 
definitely break the build process.

Are you asking to include support for TCP wrappers by adding the tcp_wrapper 
package to ESOS? If so, which existing package(s) would utilize it?

--Marc

Original comment by msmith...@gmail.com on 12 Feb 2014 at 9:12

GoogleCodeExporter commented 9 years ago
Hi Marc,

I have already realized that it's not a good idea to change CPPFLAGS, sorry.

It seems that a bunch of things, at least, glue/stonith, mysql (unless building 
it --without-libwrap),  nrpe, opensm, openssh and maybe more, made use of 
libwrap.

I also found that there exist dependencies on libgcrypt (used by gnutls, 
libxslt, nettle and depends on libgpg-error), gnutls (used by pacemaker and 
depends on libtasn1, nettle).

--Huiqun Zhou

Original comment by hqz...@nju.edu.cn on 13 Feb 2014 at 8:11

GoogleCodeExporter commented 9 years ago
Lots of packages that ESOS utilizes have optional dependencies that might 
provide additional features in those packages. We certainly don't satisfy all 
of those dependencies -- we only build what we need.

Do you have a need for the libwrap and/or libgcrypt libraries in any of those 
packages you mentioned? If so, how would you use them with ESOS? Or are you 
simply trying to satisfy all optional dependencies?

Point being that if we don't need it, we don't want to include it.

--Marc

Original comment by msmith...@gmail.com on 13 Feb 2014 at 3:35

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Hi, Marc,

This time I downloaded the esos source again, and added your "--without-udev" 
to configure of utils-linux. You can see that the dependency existed in ESOS on 
its own right. For example, below is the snippet of output when compiling 
pacemaker, which shows its link to gnutls:
libtool: link: gcc -specs=/home/build/esos-0.1-r571/work/esos_build.spec 
-nostdinc -idirafter /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include -idirafter 
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include-fixed -g -O2 -I/usr/include 
-I/usr/include/heartbeat 
-I/home/build/esos-0.1-r571/work/image/usr/include/corosync 
-I/home/build/esos-0.1-r571/work/image/usr/include/corosync -ggdb 
-fgnu89-inline -fstack-protector-all -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels 
-Wfloat-equal -Wformat=2 -Wformat-security -Wformat-nonliteral 
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wno-long-long 
-Wno-strict-aliasing -Wunused-but-set-variable -Wpointer-arith 
-Wstrict-prototypes -Wwrite-strings -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/usr/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/usr/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/usr/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/usr/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/ibsanos-0.9-r571/work/image/usr/lib -Wl,-rpath-link 
-Wl,/home/build/ibsanos-0.9-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/ibsanos-0.9-r571/work/image/usr/lib -o .libs/pacemakerd 
pacemaker.o corosync.o -Wl,-rpath-link 
-Wl,/home/build/ibsanos-0.9-r571/work/image/lib -Wl,-rpath-link 
-Wl,/home/build/esos-0.1-r571/work/image/usr/lib  
-L/home/build/esos-0.1-r571/work/image/lib 
-L/home/build/esos-0.1-r571/work/image/usr/lib 
../lib/cluster/.libs/libcrmcluster.so -lcpg -lcfg -lcmap -lquorum 
/home/build/esos-0.1-r571/work/build/pacemaker-1.1.8/lib/fencing/.libs/libstonit
hd.so 
/home/build/esos-0.1-r571/work/build/pacemaker-1.1.8/lib/common/.libs/libcrmcomm
on.so ../lib/common/.libs/libcrmcommon.so -lgnutls -lcorosync_common -lplumb 
-lpils -lbz2 -lxslt -lxml2 -lc -luuid -lrt -ldl -ltinfo -lglib-2.0 -lltdl -lqb
echo Creating pacemakerd.8
Creating pacemakerd.8

-- Huiqun

Original comment by hqz...@nju.edu.cn on 15 Feb 2014 at 5:54

GoogleCodeExporter commented 9 years ago
Please refer to the Website of pacemaker, gnutls-devel (so alternatively, 
source code) is listed as "build dependencies": 
https://github.com/ClusterLabs/pacemaker

I think if you check out the source to a new folder and build esos there, you 
could duplicate the issue I encountered.

-- Huiqun

Original comment by hqz...@nju.edu.cn on 15 Feb 2014 at 7:05

GoogleCodeExporter commented 9 years ago
Hi,

I don't understand comment #6. Either way, what is happening is many of these 
packages have things like /lib, /usr/lib, and /usr/include hard-coded in their 
autoconf scripts. We try our hardest to only include ESOS's library paths and 
pre-processor paths so this doesn't happen, but again, many of these local 
paths are put into the configure scripts, which is unfortunate for us.

In your example, pacemaker attempts to include gnutls on your system since the 
configure script detected it (installed locally on your system) and then tries 
to build with it. Even if you were successful in getting pacemaker to build 
with gnutls, the software would never actually run in ESOS since gnutls would 
not be installed into the image (its not included with ESOS).

So, what are our options for solving this globally in ESOS:
- Use a chroot environment -> This is out since then we would need to include 
all build tools in this environment, and since we're include the build tools 
with ESOS, I'd rather not do this. Unless someone can think of a cleaner way, 
this option is out.
- Somehow globally masking /lib, /usr/lib, /usr/include, etc. during the ESOS 
build. And we can entirely do that since then the build tools themselves (eg, 
gcc) would not run due to missing dynamic libraries.
- The third option, and probably the best, but most time consuming: Almost all 
packages will attempt to auto-detect what options to enable if not explicitly 
set when the configure script runs (eg, --without-name, --with-name). Someone 
would need to explicitly set all of these configure options for every package 
and then this should eliminate the need for the configure scripts to 
auto-detect options and use things from the local system they shouldn't.

So, if you're looking to contribute, option # 3 would be the best. Until then, 
if you'd like to use ESOS, stick to the pre-built binary images; or if you 
really want to build ESOS, use a very (very) minimal install of CentOS and only 
install the required build tools.

--Marc

Original comment by msmith...@gmail.com on 15 Feb 2014 at 2:52