Re: ftruncate with LFS OFF (was Re: [PATCH v2 24/46] ftruncate: Use ftruncate64 if arch does not have the ftruncate syscall)
On 10 December 2012 05:26, Vineet Gupta vineet.gup...@synopsys.com wrote: The fix looks reasonable to me (probably similar fixes for the other syscalls apply too, except for the getdents one that looks a bit complicated.) However, I am affraid that the code might become a bit unreadable with all the #if/#def mess. !LFS support doesn't add lot more than what we already have. The 3 which seem to fail for me are easily fixable. I've not seen any breakage with getdents I will rebase the branch with fixes for all of them Another workaround for this is new architectures to always select UCLIBC_HAS_LFS in ther Kconfig files. Remember uClibc is all about smaller code footprint - this is not acceptable ! That's why I said workaround :) Thanks for testing these patches. -- Regards, Markos ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Perf compilation failure with uclibc due to libintl
Hello, Le 12/10/12 13:12, Madhu koriginja a écrit : Hi All, Perf package depends on elfutils. I am using the elfutils-0.152. elfutils package compilation failed due to libintl. I am using gcc 4.5 linaro toolchain and uclibc 0.9.32. I am able compile the same package with same toolchain successfully with glibc 2.14. With uClibc I faced the below error. Please suggest me how to solve this issue. make[7]: Entering directory `/build/build_dir/target-arm_v7-a_uClibc-0.9.32_eabi/elfutils-0.152/libdw' arm-openwrt-linux-uclibcgnueabi-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='/usr/share/locale' -DIS_LIBDW -I. -I.. -I. -I. -I../lib -I.. -I./../libelf -I/build/staging_dir/target-arm_v7-a_uClibc-0.9.32_eabi/usr/include -I/build/staging_dir/target-arm_v7-a_uClibc-0.9.32_eabi/include -I/build/staging_dir/toolchain-arm_v7-a_gcc-4.5-linaro_uClibc-0.9.32_eabi/usr/include -I/build/staging_dir/toolchain-arm_v7-a_gcc-4.5-linaro_uClibc-0.9.32_eabi/include -I/build/staging_dir/target-arm_v7-a_uClibc-0.9.32_eabi/usr/lib/libiconv-stub/include -I/build/staging_dir/target-arm_v7-a_uClibc-0.9.32_eabi/usr/lib/libintl-stub/include -std=gnu99 -Wall -Wshadow -Wunused -Wextra -fgnu89-inline -Wformat=2 -Os -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -msoft-float -I/build/staging_dir/target-arm_v7-a_uClibc-0.9.32_eabi/usr/lib/libiconv-stub/include -I/build/staging_dir/target-arm_v7-a_uClibc-0.9.32_eabi/usr/lib/libintl-stub/include -MT dwarf_begin.o -MD -MP -MF .deps/dwarf_begin.Tpo -c -o dwarf_begin.o dwarf_begin.c In file included from dwarf_begin.c:59:0: ./libdwP.h:54:21: fatal error: libintl.h: No such file or directory compilation terminated. make[7]: *** [dwarf_begin.o] Error 1 elfutils needs getext to properly build. It looks like you are using OpenWrt, so I would rather direct you to the openwrt development mailing-list, because this has nothing to do with uClibc per se. -- Florian ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Perf compilation failure with uclibc due to libintl
elfutils needs getext to properly build. It looks like you are using OpenWrt, so I would rather direct you to the openwrt development mailing-list, because this has nothing to do with uClibc per se. But I am able to compile with glibc library successfully. You mean do I need to enable some configuration for gettext in the openwrt configuration? ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- View this message in context: http://old.nabble.com/Perf-compilation-failure-with-uclibc-due-to-libintl-tp34779173p34779420.html Sent from the uClibc mailing list archive at Nabble.com. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: ftruncate with LFS OFF (was Re: [PATCH v2 24/46] ftruncate: Use ftruncate64 if arch does not have the ftruncate syscall)
On 10 December 2012 05:26, Vineet Gupta vineet.gup...@synopsys.com wrote: !LFS support doesn't add lot more than what we already have. The 3 which seem to fail for me are easily fixable. I've not seen any breakage with getdents Right now, getdents requires either NR_getdents or __getdents64 which is only compiled for LFS (see libc/sysdeps/linux/common/Makefile.in, line 14 were are *64.c files are only available for LFS). So at the moment, getdents fails in a uClibc w/o LFS with undefined references to __getdents64. The fix is similar to the other functions but in this case the code in __getdents ( for WORDSIZE == 32 ) will become a bit unreadable. -- Regards, Markos ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: iozone compilation failure with uclibc due to aio
On Mon, Dec 10, 2012 at 05:43:54PM +0530, Madhu koriginja wrote: Hi All, I am facing compilation issue with the iozone compilation failure with uclibc library. I am using the uclibc 0.9.32 version, gcc 4.5 linaro toolchain. The same code is compiling with the gcc 4.5 linaro toolchain and glibc 2.14. Please help me to resolve this issue. Please see the compilation error below: [...] arm-openwrt-linux-uclibcgnueabi-gcc -c -O3 -Dunix -Dlinux -DHAVE_ANSIC_C -DASYNC_IO \ -D_LARGEFILE64_SOURCE -Os -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -msoft-float libasync.c -o libasync.o libasync.c:98:17: fatal error: aio.h: No such file or directory compilation terminated. As far as I know, uClibc does not implemnt the AIO part of POSIX. Is there perhaps any way to make iozone use some fallback in place of AIO? It's not like POSIX AIO is a particularly well-designed API that anybody would actually WANT to use... If there's really no way around it, you could see if someone could help you getting AIO added to uClibc. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: iozone compilation failure with uclibc due to aio
On Mon, Dec 10, 2012 at 09:56:38PM +0100, Laurent Bercot wrote: As far as I know, uClibc does not implemnt the AIO part of POSIX. Is there perhaps any way to make iozone use some fallback in place of AIO? It's not like POSIX AIO is a particularly well-designed API that anybody would actually WANT to use... Hello Rich, From a purely theoretical/academic point of view, as a software engineer, I'm interested in knowing the details of why you think AIO is badly designed. Not saying I disagree (I've never used that part of POSIX so I don't know it enough to have an opinion), I'd just like to hear your arguments about it. Perhaps my opinion is influenced by the ugliness and broken corner cases that arise trying to implement it in userspace on top of orginary POSIX IO functions and threads. See the glibc bug I just submitted, #14942: http://sourceware.org/bugzilla/show_bug.cgi?id=14942 In fairness, our implementation in musl is at present just as broken as glibc's and probably more broken. Still, I think there's a lot of ugliness inherent in the API. Some things that come to mind: 1. Having to submit your requests with a structure containing the arguments rather than with function arguments. It would be better if the arguments (like fd, offset, etc.) were actual function arguments and you got back an opaque handle for the request (rather than having internal stuff hidden in the non-opaque aiocb buffer). This can of course be fixed by wrapping the API, so it's not a huge issue. 2. Use of sigevent for completion-notification. SIGEV_THREAD has a lot of flaws that make it virtually impossible to use correctly, so you're stuck with signals, which involve nasty global state and aren't library-safe. This is more a complaint about sigevent's poor specification in general than about AIO in particular, but it's pretty much a show-stopper if you want asynchronous delivery of completion notification in a library; it certainly crosses the point at which it becomes easier, safer, AND cleaner to just roll your own async IO using threads. 3. Underspecified corner-cases, like whether there's any ordering between AIO requests on different file descriptors that refer to the same underlying open file description or even just the same underlying file (with a different open file description). If it's too off-topic for the list, we can take the discussion to private, but I believe other readers could be interested in it too. I don't think it's too off-topic. Certainly if this feature is to be added to uClibc, there should be an understanding of what's ugly about it and what makes it so difficult to get right. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
