If LD_LIBRARY_PATH is set to any value, build will fail, example:
Making check in doc
...
/bin/bash: line 1: /usr/lib/libeatmydata: No such file or directory
...
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906480
Same is true for DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH.
This bug was introduced with commit 19442df2cd
where Kota removed evals, but forgot to remove prepending of same env
variables.
Change-Id: Ib7a1d6b839d4a207ee0471b55233e1ce5d958705
This patch fixes automake tools warnings as follows (and a my fault
in previous patch [1]):
- Change INCLUDES variable to APP_CPP_FLAGS and APP_C_FLAGS according to
the warning message
- Remove non-POSIX variable to suppress that warnings
Note that the latter change may be affected to the testing so please
be careful on your review what's going on your testing environment.
In the past change [2], they ware designed to use the shared
object binaries in the build path. However, Daniel had pointed out the good
thing at [1] if we runs the test/liberasruecode_test (it's shell with linker)
in the dir, we can touch the expected binaries.
My fault in the previous patch is that I didn't replace
./test/.libs/liberasurecode_test to ./test/liberasurecode_test even
we use --trace-children=yes option for the valgrind.
Now, all tests run via ./test/<test name> syntax and IMO no matters
exist even if we remove the non-POSIX variable for test settings.
1: https://review.openstack.org/#/c/434162
2: 93446db941
Change-Id: I0e79bed7755a1f286b746a70fcf56fdc972bfd5d
Can you believe that we ware testing the memory leak with valgrind
to just *bash scripts* instead of actual binaries on liberasurecode_test
and libec_slap?
That is why we cannot find such an easy memory leak[1] at the gate.
Now this patch enable to run the valgrind against to the binaries.
With this fix, we found various memory leak at liberasurecode_test as
follows and this patch also fixes them:
- If we create fake fragments, we're responsible for freeing all of the
frags as well as the array holding the pointers to the frags.
- If we allocate any space, we're responsible for freeing it.
- If we create an EC descriptor, we're responsible for destroying it.
- If we create a fragment or skip array, we're responsible for freeing it.
- If that happens inside a loop, we're responsible for doing it *inside
that same loop*.
In addition to the test fix, this patch fixes following memory leaks at
the code which is affected to other users (pyeclib, OpenStack Swift)
* Refuse to decode fragments that aren't even long enough to include
fragment headers.
* Fix a small memory leak in the builtin rs_vand implementation.
Closes-Bug: #1665242
Co-Authored-By: Tim Burke <tim@swiftstack.com>
1: https://review.openstack.org/#/c/431812
Change-Id: I96f124e4e536bbd7544208acc084de1cda5c19b2
Debian maintainers reported that liberasurecode could
not be built reproducibly.
What happens is that erasurecode_version.h headers are
non-determinstically installed in the target directory
depending on the system clock. This is due to
debian/tmp/usr/include not being created and the
install-exec-hook ignores errors.
The attached patch ensures target ${includedir} exists
and therefore the headers will always be there.
Signed-off-by: Chris Lamb <lamby@debian.org>
Users of liberasurecode <= 1.0.7 used alloc/free helpers
(which they shouldn't have). This change is to make sure
we are still able to those older revs of programs and they
work with newer liberasurecode.
Ondřej Nový