Closed GoogleCodeExporter closed 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
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
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
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
[deleted comment]
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
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
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
Original issue reported on code.google.com by
hqz...@nju.edu.cn
on 9 Feb 2014 at 5:15