unable to specify libcerror in a system folder
Closed this issue · 18 comments
I have installed libcerror in a system folder /usr/lib64/libcerror* properly and was hoping to use --with-libcerror flag to enforce it, however autogen.sh script fails before that. There are few checks which are trying to find it in a local folder so I had to remove them with the following:
sed -i -e '/libcerror\/Makefile/d' configure.ac
sed -i -e '/libcerror/d' Makefile.am
The other libraries libbfio libcdata libcfile libclocale libcnotify libcpath libcsplit libfdatetime libfguid libuna are likely affected as well but I have not checked it yet.
however autogen.sh script fails before that
can you indicate how it is failing? or the error it provides?
here we go:
***** automake *****
***** PWD: /var/tmp/portage/dev-libs/libcthreads-20170101_alpha/work/libcthreads-20170101
***** automake --add-missing --copy --foreign --force-missing
configure.ac:38: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
configure.ac:38: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
configure.ac:38: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
configure.ac:19: installing './compile'
configure.ac:11: installing './missing'
Makefile.am: installing './INSTALL'
configure.ac:121: error: required file 'libcerror/Makefile.in' not found
Makefile.am:3: error: required directory ./libcerror does not exist
libcthreads/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
I see, you are building the source from git (for development purposes) and do not have a local copy of libcerror. Please have a look at https://github.com/libyal/libcthreads/wiki/Building#read-first and https://github.com/libyal/libcthreads/wiki/Building#git. It should clarify the steps necessary to build from git.
I'm pretty sure it's a problem at your end because both configure.ac and Makefile.am have hardcoded references to the local folder, for example, configure.ac has the following:
AC_CONFIG_FILES([libcerror/Makefile])
So that line fails if I have libcerror installed in a system directory.
Similarly, Makefile.am has the follow:
libcerror
...
cd $(srcdir)/libcerror && $(MAKE) $(AM_MAKEFLAGS)
...
(cd $(srcdir)/libcerror && $(MAKE) splint $(AM_MAKEFLAGS))
It works just fine if I remove these.
based on the output you provided:
configure.ac:121: error: required file 'libcerror/Makefile.in' not found
Makefile.am:3: error: required directory ./libcerror does not exist
this indicates to me synclibs.sh was not run (or it failed) before autogen.sh
I'm intentionally not running it because libcerror installed as a shared library:
equery f libcerror
* Searching for libcerror ...
* Contents of dev-libs/libcerror-20170101_beta:
/usr
/usr/include
/usr/include/libcerror
/usr/include/libcerror.h
/usr/include/libcerror/definitions.h
/usr/include/libcerror/extern.h
/usr/include/libcerror/features.h
/usr/include/libcerror/types.h
/usr/lib64
/usr/lib64/libcerror.a
/usr/lib64/libcerror.so -> libcerror.so.1.0.0
/usr/lib64/libcerror.so.1 -> libcerror.so.1.0.0
/usr/lib64/libcerror.so.1.0.0
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/libcerror.pc
/usr/share
/usr/share/doc
/usr/share/doc/libcerror-20170101_beta
/usr/share/doc/libcerror-20170101_beta/AUTHORS
/usr/share/doc/libcerror-20170101_beta/ChangeLog.bz2
/usr/share/doc/libcerror-20170101_beta/README.bz2
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/libcerror.3.bz2
I understand, but for the libyal libraries it does not work like that.
Can you improve the code and make it optional please?
At Gentoo, we are trying to bundle libraries. There are multiple reasons for that, please see the following:
https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
Can you improve the code and make it optional please?
It already is optional, --with-libcerror works with the source distribution version.
What you are running into is that you're not using a redistribute-able version of the source, but a development version. Here you have consider the development and source release as 2 different versions.
Ok, give me a bit of time, I will test it with redistributeable source.
I find the option --with-libcerror a bit absolute because it works the same with and without it.
The autoconfigure script detect automatically and indicates "yes" or "local" regardless of the option.
Shouldn't it fail if I enable it and the script did not find the library in a system (default) or specified location?
I find the option --with-libcerror a bit absolute because it works the same with and without it.
In your opinion why should it fail?
Shouldn't it fail if I enable it and the script did not find the library in a system (default) or specified location?
It could, though most users find this annoying UX
Unless I'm wrong again, this option does nothing right now. The script automatically detect system library first and falls back to local if it is not available. So it would be good to know that the tool fail to find a system (or in path) library if a user specified that option intentionally.
So it would be good to know that the tool fail to find a system (or in path) library if a user specified that option intentionally.
when it does, the summary will show libcerror instead of local
yes, but it scrolls up quickly when it doesn't it. This is actually related to all libc* libraries and all parameters. It is hard and almost impossible to observe this little hint during compilation, especially when I compile all 11 libraries at once, and my intention to make sure that all system libraries (with their dependencies) are found
what I could do is add a configuration option that will error if --with-X is defined but no suitable source was found. Note that this will not only check for existence but also for version and/or availability of required functions.
Moving to libyal/libyal#64