Commit 851f685993 ("Makefile: Add dependency between libvmcp and
libutil to fix -j builds") introduced the following regression
$ make clean
CLEAN /home2/holzheu/src/s390-tools
...
CLEAN libccw
CC libutil/util_base.o
CC libutil/util_path.o
For the "clean" target the new library dependency triggers a build
of libutil.
So remove the dependency again.
To fix the parallel build issue, no longer build the examples with
"make all" and add a new target "examples" that can now be used for building
the example programs.
Fixes: 851f685993 ("Makefile: Add dependency between libvmcp and libutil to fix -j builds")
Signed-off-by: Michael Holzheu <holzheu@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The strlcpy() implementation in libu2s is beneficial for other tools as
well. Move the implementation to libutils and replace misc_strlcpy() in
libu2s accordingly.
Change the link order in zipl to make it build again.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The util_scandir_* functions may return 0 or -1, in which case no vector
is allocated in libutil/util_scandir.c. util_ptr_vec_free, called by
util_scandir_free or directly from lschp.c and lsscm.c, does always
call free for the vector which might be not initialized.
Fix this by always initializing the vector with NULL in __scandir and
add some api hardening by checking the vector and count in
util_ptr_vec_free before iterating over the vector.
And update the comment for util_scandir to indicate that -1 may be
returned in error cases plus that the vector is initialized with NULL.
Fixes: https://github.com/ibm-s390-tools/s390-tools/issues/43
Reported-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add missing long options for --help and --version in util_prg_example.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This patch
- moves function util_strstrip to libutil/util_libc.c and deletes the
extra files util_strstip.[ch]
- adds doxygen comments for util_strstrip()
- provides an example on how to use util_strstrip().
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Function strstrip strips leading and trailung
spaces from a given string.
During review it was decided to move this function
to the libutil library to make it available for other tools.
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since now util_list_new() internally fails for out-of-memory situations,
we can also remove some NULL pointer checks.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
When building libutil in parallel, it can happen that the archive
file is created twice:
$ cd libutil
$ make -j
...
CC libutil/util_rec_example.o
AR libutil/libutil.a
AR libutil/libutil.a
LINK libutil/util_base_example
This can lead to the following build error:
$ make -j OPT_FLAGS="-pipe"
..//libutil/libutil.a(util_path.o): In function `sys_mount_point':
util_path.c:56: undefined reference to `util_proc_mnt_get_entry'
util_path.c:60: undefined reference to `util_proc_mnt_free_entry'
collect2: error: ld returned 1 exit status
../common.mak:232: recipe for target 'util_path_example' failed
The problem is that the following rule from common.mak is triggered in
the libutil directory:
$(rootdir)/libutil/libutil.a: $(rootdir)/libutil
$(MAKE) -C $(rootdir)/libutil/ libutil.a
.PHONY: $(rootdir)/libutil
To prevent this rule, use the local "libutil.a" as dependency for the
example binaries.
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>