manpages-oops & malloc problem

Kevin Day msu-kday at student.mcneese.edu
Sun Dec 18 08:49:05 PST 2005


First Problem:
I noticed that in your Changelogs, the man1x's were installed in man1 (which
was fixed in rc3).
I then noticed that (in rc3 as well) man3x and man5x have the same issue.
They should be installing in man3x and man5x, but they are installing in man3
and man5.

---------
Second problem:
I have been having problems getting Xorg to start.  "Cannot Call Malloc" or
"Cannot Perform Malloc".
Since I am using uClibc-0.9.28, I have been believing this was solely a uClibc
problem.  However, I suddenly noticed that during the configure time, "does
malloc return NULL" fails.  And yet, in my uClibc configure, I have it
specifically returning NULL from malloc (for malloc(0)).
Looking into the config.log I noticed the following:

configure:8053: checking whether malloc(0) returns NULL
configure:8071: gcc -o conftest    conftest.c  >&5
conftest.c:2: warning: conflicting types for built-in function 'malloc'
conftest.c: In function `main':
conftest.c:4: error: `NULL' undeclared (first use in this function)
conftest.c:4: error: (Each undeclared identifier is reported only once
conftest.c:4: error: for each function it appears in.)
configure:8074: $? = 1
configure: program exited with status 1
configure: failed program was:
| 
| char *malloc();
| main() {
|     exit(malloc(0) == NULL ? 0 : 1);
| }
configure:8093: result: no
configure:8244: creating ./config.status

This is found in all config.logs that test malloc's return ability.

Malloc, was not failing, it was NULL, which for some reason is not declared. 
This probably means uClibc was not defining it where expected.
However, using an #ifndef NULL .. etc .. should prevent this particular
incident from happening.  Or is this undersirable?  Is NULL expected to be some
sort of Live-Pointer as in glibc in this case?

P.S. Could this malloc problem create a "cannot call assert" problem? (in which
I get when I work around the malloc problem that prevents X from starting.)
-- 


More information about the xorg-modular mailing list