Re: libwww contributions

Arthur Smith wrote:

> Vic Bancroft wrote:
>
>> Arthur Smith wrote:
>>
>>> I had trouble compiling the latest (CVS) under solaris, anybody else 
>>> tried this? 
>>
>> Ouch, could you send a compile log ?
>
> Hi Vic - notice there are a bunch of 'regparm' warnings as well, but 
> the error is with some dirent/direct stuff in HTFile.c:

Yea, I get the regparm warnings on a sparc machine running netbsd with 
gcc version 2.95.3.  Of course that environment is so crusty, it dies in 
some other strange way using libtool on md5.c . . .

Nevertheless, the way your build is failing seems directly related to 
the introduction of the new function to calculate an appropriate name 
buffer size in the dirent struct.

> This is on Sun Solaris 9, sparc (not x86) platform, with gcc 3.3 - do 
> you want the full config.log?

Yes, if you do not mind, please send me the config log . . .

> make  all-recursive
> make[1]: Entering directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww'
> Making all in config
> make[2]: Entering directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/config'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/config'
> Making all in modules
> make[2]: Entering directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/modules'
> Making all in expat
> make[3]: Entering directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/modules/expat'
> /bin/bash ./libtool --silent --mode=compile gcc -g -O2 -Wall 
> -Wmissing-prototypes -Wstrict-prototypes -fexceptions   -I./lib -I. -o 
> lib/xmlparse.lo -c lib/xmlparse.c
> In file included from lib/xmlparse.c:94:
> lib/xmltok.h:143: warning: `regparm' attribute directive ignored
> lib/xmltok.h:144: warning: `regparm' attribute directive ignored
>
This warning is expected behavior.  Since the regparm attribute, used on 
i386 machines to pass arguments using registers, is unsave for global 
functions in shared libraries on some ELF systems. 

Perhaps we could detect the operating systems on which gcc will issue 
the warning and #define PTRFASTCALL in modules/expat/lib/internal.h 
appropriately . . .

> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include 
> -I../../modules/md5 -I../../modules/expat/lib 
> -DW3C_ICONS=\"/home/jis/resdev/apsmith/share/w3c-libwww\" -g -O2 -Wall 
> -MT HTBind.lo -MD -MP -MF .deps/HTBind.Tpo -c HTBind.c -o HTBind.o 
> >/dev/null 2>&1
> if /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H 
> -I. -I. -I../.. -I/usr/local/include -I../../modules/md5 
> -I../../modules/expat/lib 
> -DW3C_ICONS=\"/home/jis/resdev/apsmith/share/w3c-libwww\"   -g -O2 
> -Wall -MT HTFile.lo -MD -MP -MF ".deps/HTFile.Tpo" -c -o HTFile.lo 
> HTFile.c; \
> then mv -f ".deps/HTFile.Tpo" ".deps/HTFile.Plo"; else rm -f 
> ".deps/HTFile.Tpo"; exit 1; fi
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include 
> -I../../modules/md5 -I../../modules/expat/lib 
> -DW3C_ICONS=\"/home/jis/resdev/apsmith/share/w3c-libwww\" -g -O2 -Wall 
> -MT HTFile.lo -MD -MP -MF .deps/HTFile.Tpo -c HTFile.c  -fPIC -DPIC -o 
> .libs/HTFile.o
> HTFile.c:702:2: #error "buffer size for readdir_r cannot be determined"
> HTFile.c: In function `HTFile_dirent_buf_size':
> HTFile.c:705: warning: implicit declaration of function `offsetof'
> HTFile.c:705: error: parse error before "struct"
> make[5]: *** [HTFile.lo] Error 1
> make[5]: Leaving directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/Library/src'
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/Library/src'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/Library/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww/Library'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory 
> `/home/jis/resdev/apsmith/src/w3c-libwww-cvs/libwww'
> make: *** [all] Error 2

Ouch.  It does seem a tad harsh that just missing a NAME_MAX macro just 
signals an error. 

Perhaps Solaris 9 doesn't have all it's POSIX definitions sorted out the 
way we are using it from /usr/include/dirent.h. 

Does Solaris make the BSD equivalent MAXNAMLEN in 
/usr/include/sys/dirent.h ?

Of course, we could be safer and use the FILENAME_MAX macro for the 
stdio.h crowd, it is set to 4096 on my system. 

In any case, to get past the compile error, you could try to replace 
line 702 with

               name_max = 4096;

What do you think Ben ?

more,
l8r,
v

-- 
"The future is here. It's just not evenly distributed yet."
 -- William Gibson, quoted by Whitfield Diffie

Received on Tuesday, 29 November 2005 04:25:14 UTC