[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnuastro-commits] master 3c66819: Removed rpl_malloc discussion from kn
From: |
Mohammad Akhlaghi |
Subject: |
[gnuastro-commits] master 3c66819: Removed rpl_malloc discussion from known issues |
Date: |
Fri, 28 Oct 2016 11:43:11 +0000 (UTC) |
branch: master
commit 3c66819c8cd34e7dd4fc90fa4af1d1f726654241
Author: Mohammad Akhlaghi <address@hidden>
Commit: Mohammad Akhlaghi <address@hidden>
Removed rpl_malloc discussion from known issues
The Known issues section of the book had a discussion on the `rpl_malloc'
error can appear when doing `make check' (bug #49459). But since this bug
was fixed in the previous commit (32a2dd9), this explanation is no longer
necessary.
---
doc/gnuastro.texi | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/doc/gnuastro.texi b/doc/gnuastro.texi
index ad0aa7a..d911291 100644
--- a/doc/gnuastro.texi
+++ b/doc/gnuastro.texi
@@ -3804,22 +3804,6 @@ installed from source.} Similar to the case for
@file{LDFLAGS}
@command{CPPFLAGS=-I/usr/local/include} to @command{./configure} to
re-configure Gnuastro, then re-run make.
address@hidden
address@hidden @code{rpl_malloc}
address@hidden GNU portability library
address@hidden make check}: @emph{Complaint about @code{rpl_malloc} before the
-tests begin.} This is a problem with the different ways different operating
-systems implement C's @code{malloc} function. It doesn't happen when
-building Gnuastro with @command{$ make} because the GNU Portability Library
-(Gnulib) is used to compensate for the differences. But in @command{make
-check}, Gnulib is not used, so this error might pop-up there. To fix it,
-please re-run configure like below (adding any other options/arguments you
-might have already used):
-
address@hidden
-./configure ac_cv_func_malloc_0_nonnull=yes
address@hidden example
-
@cindex Tests, only one passes
@cindex @file{LD_LIBRARY_PATH}
@item
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gnuastro-commits] master 3c66819: Removed rpl_malloc discussion from known issues,
Mohammad Akhlaghi <=