A Simple Compatability Question
Heinrich.Mislik at univie.ac.at
Thu Feb 12 13:54:46 GMT 2004
On 12 Feb 2004, at 21:15, Andrew Bartlett wrote:
> > Samba compiles with -D_LINUX_SOURCE_COMPAT, this breaks malloc in 64-
> > Bit mode. I configured with 'CFLAGS=-U_LINUX_SOURCE_COMPAT'.
> Can you give me some more detail on that?
This is from /usr/include/stdlib.h (_ALL_SOURCE is defined)
#if defined(_ALL_SOURCE) && defined(_LINUX_SOURCE_COMPAT)
extern void *__linux_malloc();
extern void *__linux_realloc();
extern void *__linux_calloc();
extern void *__linux_valloc();
extern void *__linux_malloc(size_t);
extern void *__linux_realloc(void *, size_t);
extern void *__linux_calloc(size_t, size_t);
extern void *__linux_valloc(size_t);
I couldn't find anything about __linux_malloc() but the following
documents that it is not suitable for 64 Bit:
# cat malloc_broken.c
char *p = malloc(10);
# cc -q32 -D_LINUX_SOURCE_COMPAT malloc_broken.c
# cc -q64 -D_LINUX_SOURCE_COMPAT malloc_broken.c
Segmentation fault (core dumped)
# cc -q64 malloc_broken.c
The 64-bit Pointer is truncated to 32 bit!
> > configure finds strndup and strnlen, both are broken. I changed
> > config.h after configuration accordingly. Otherwise 'mangling method
> > = hash2' will not work under certain conditions.
> Can you please define broken? Is it that the prototypes are not
> correctly defined, and therefore cast-to-int causes problems, or is it
> something else?
# cat strnlen_broken.c
char *s1 = "01234567891";
# cc strnlen_broken.c
strnlen should return 10!
I couldn't find a short example of the wrong behavior of strndup.
When i insterted DEBUG befor and after strndup in the Samba code, I
saw that no '\0' is put on the end. So sometimes I saw remainings of
previously used strings after the duplicated string.
> In both cases, can you write a configure test to fix it (either use our
> internal strndup/strnlen, or include the right headers for the
Not to sure about configure tests, but the above should help.
Note that cc is IBMs "vac.C 220.127.116.11 C for AIX Compiler" on AIX 5.2.
After writing the previous mail I found another issue with AIX:
I tested CPANs Filesys::SmbClient and got "timeout connecting to ..."
when connecting to the same host with smbclient worked fine. The
reason is, that due to the way the CPAN module was linked, the
function msleep from AIX was used indstead of samba's msleep. From
int msleep (Sem)
msemaphore * Sem;
The msleep subroutine puts a calling process to sleep when a
semaphore is busy.
The function immediatly returned with EFAULT and therefor the timeout
occurred much too early. Samba should use another name. Compiling
with -Dmsleep=smb_msleep solved it for me.
Zentraler Informatikdienst der Universitaet Wien
A-1010 Wien, Universitaetsstrasse 7
Tel.: (+43 1) 4277-14056, Fax: (+43 1) 4277-9140
More information about the samba-technical