Date: Thu, 24 Jan 2013 20:28:37 +0100 From: Alexander Stadler <sa.musl@...vie.ac.at> To: musl@...ts.openwall.com Subject: Re: unknown type name 'loff_t' Am 24.01.2013 20:19, schrieb Rich Felker: > On Thu, Jan 24, 2013 at 07:57:28PM +0100, Alexander Stadler wrote: >> Am 23.01.2013 18:37, schrieb Rich Felker: >>> On Wed, Jan 23, 2013 at 06:33:42PM +0100, Alexander Stadler wrote: >>>> Thanks for your fast responses. >>>> >>>> The other error I'm currently running into is >>>> >>>> make: Entering directory `/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/uboot-envtools-2012.04.01' >>>> mips-openwrt-linux-musl-gcc -Wall -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -mno-branch-likely -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -I/space/build-trunk/trunk/staging_dir/target-mips_r2_musl-0.9.8/usr/include -I/space/build-trunk/trunk/staging_dir/target-mips_r2_musl-0.9.8/include -I/space/build-trunk/trunk/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_musl-0.9.8/usr/include -I/space/build-trunk/trunk/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_musl-0.9.8/include crc32.c fw_env.c fw_env_main.c -o fw_printenv >>>> fw_env.c:643:55: error: unknown type name 'loff_t' >>>> fw_env.c: In function 'flash_read_buf': >>>> fw_env.c:680:2: error: unknown type name 'loff_t' >>>> fw_env.c:713:3: warning: implicit declaration of function 'flash_bad_block' [-Wimplicit-function-declaration] >>>> fw_env.c: In function 'flash_write_buf': >>>> fw_env.c:777:2: error: unknown type name 'loff_t' >>>> make: *** [fw_printenv] Error 1 >>>> make: Leaving directory `/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/uboot-envtools-2012.04.01' >>> >>> Where is loff_t being used? It's probably the wrong type to use. The >>> only APIs loff_t is to be used with are under _GNU_SOURCE, so if you >>> don't need -D_GNU_SOURCE to get the functions, it's doubtful that >>> loff_t should be used. These functions are in fcntl.h, and it will >>> #define loff_t off_t when _GNU_SOURCE is defined, so either >>> -D_GNU_SOURCE or -Dloff_t=off_t would be a workaround, but I think the >>> issue should be investigated to determine if there's code that needs >>> to be fixed or if there are other circumstances under which loff_t >>> should be exposed by musl. >>> >>> Rich >> >> It's used in >> http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=tools/env/fw_env.c;h=37b60b80a7624566d9ecefdd04c0658134bd654d;hb=HEAD >> where (you were absolutely right) a #include <fcntl.h> exists. >> And -D_GNU_SOURCE helped. Thank you! > > It looks like some ioctl interfaces also request loff_t in their > official usage, so musl should do something to ensure it's exposed for > ioctl. I'm not sure however what the best way is. Simply adding > > #define loff_t off_t > > to sys/ioctl.h is not sufficient because off_t might not be defined, > so another header would need to be included to get off_t. Note that > sys/ioctl.h is not under the domain of any modern standard, so it > would not be a horrible offense to make it include extra junk if we > need to.. > >> Happy about that, unfortunately there will come up much more things >> I think, as seconds later the next undeclared error popped up.. > > OK, I'll take a look. > >> (when compiling mtd >> mips-openwrt-linux-musl-gcc -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -mno-branch-likely -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -Dtarget_ar71xx=1 -Wall -DFIS_SUPPORT=1 -I/space/build-trunk/trunk/staging_dir/target-mips_r2_musl-0.9.8/usr/include -I/space/build-trunk/trunk/staging_dir/target-mips_r2_musl-0.9.8/include -I/space/build-trunk/trunk/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_musl-0.9.8/usr/include -I/space/build-trunk/trunk/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_musl-0.9.8/include -Wall -c -o fis.o fis.c >> fis.c: In function 'fis_open': >> fis.c:80:64: error: 'MAP_LOCKED' undeclared (first use in this function) >> fis.c:80:64: note: each undeclared identifier is reported only once for each function it appears in >> >> So I wonder why uClibc? seems to include these things. But there are >> so many mman.h's and the one referenced from fis.c (sys/mman.h) >> seems not to have the define, but otheres have.. . How could a >> proper procedure look like to include these things, and on which >> side of the code this should go is what I currently don't understand >> at all. I just don't want to bother you if its bad behaviour of >> Uclibc which enabled this things to work. But than propably an >> generic workaround could be found. > > MAP_LOCKED is a Linux extension to mmap that somehow never got added > to musl when the others were added. Its definition probably varies > per-arch. I'll see if I can get somebody to find what's needed to add > it correctly for all archs. You're right, unfortunately it varies. http://lxr.free-electrons.com/ident?i=MAP_LOCKED > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.