Hi,
איתי שוורץ wrote,
> sure,
>
> The following program compiled using gcc-7.2 binutils-2-29.1 uclibc-ng (newest
> from git):
> user@yitai:~/test$ cat test.c
> #include <stdlib.h>
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void) {
> return 0;
> }
>
> with the patch:
>
> user@yitai:~/test$ make
> x86_64-unknown-linux-uclibc-gcc test.c -o test -static
> wc -c test
> 45248 test
>
> without the patch:
>
> user@yitai:~/test$ make
> x86_64-unknown-linux-uclibc-gcc test.c -o test -static
> wc -c test
> 52592 test
>
> As you can see, The patch save 7344 bytes (about %14 precent smaller) for
> x86_64.
Thanks, applied and pushed,
best regards
Waldemar
Hi,
I've upgraded Optware-ng uClibc-ng from 1.0.15 to 1.0.26 a while ago. It
called for recompilation of most of the packages, but this issue seems to
be resolved now. The issue I'd like to report is that when the linker
(ld-uClibc.so.0) is built, UCLIBC_RUNTIME_PREFIX seems to evaluate to "/",
even though RUNTIME_PREFIX is set to "/opt" (see attached config). I had to
resort to patching uClibc-ng sources (
https://github.com/Optware/Optware-ng/blob/master/sources/buildroot-armeabi…,
%OPTWARE_TARGET_PREFIX% is replaced with "/opt") to get this fixed. It
wasn't so with 1.0.15, setting RUNTIME_PREFIX to "/opt" made linker look
for libs only in "/opt/lib", "/opt/usr/lib", etc., and not in "/lib" and
such. Is this change intended, or is it a bug?
Thanks,
Alex
P.S. Another thing I noticed that you may want to know. Looking
at ldso/ldso/dl-elf.c, this line seems to be wrong:
> UCLIBC_RUNTIME_PREFIX "usr" LDSO_MULTILIB_DIR,
since LDSO_MULTILIB_DIR defaults to "lib" -- not "/lib", so I'm guessing
you want it this way:
> UCLIBC_RUNTIME_PREFIX "usr/" LDSO_MULTILIB_DIR,
Hi,
Yitai Schwartz wrote,
> sysconf creates a lot of code dependencies.
> getpagesize dosen't.
> staticly linked code that calls malloc is now much smaller.
Thanks for the patch. Can you show us some results of the
savings?
best regards
Waldemar
Hi, Waldemar
> @Guo: Do you think this is the right patch?
It's OK, and we should put the "elif __NR_socketcall" to every
socketcall syscall implementation.
> What happens if an application tries to use recvmmsg running on an
> older Kernel, will it crash or just do nothing?
>
Kernel will return -EINVAL, no crash.
best regards
Guo Ren
Hi all,
I'm facing a compilation error while building GCC 7.2.0 libgo with
uClibc-ng 1.0.26 with this error:
runtime_sysinfo.go:418:17: error: use of undefined type
‘___uclibc_locale_struct’
Here is the relevant build output: https://pastebin.com/B7urxS2m
The problematic runtime_sysinfo.go is created using -fdump-go-spec: it's
used to automatically generate Go declarations from C code (see
https://golang.org/doc/install/gccgo#Automatic_generation_of_Go_declaration…).
The generated gen-sysinfo.go is indeed missing ___uclibc_locale_struct
declaration.
Looks like -fdump-go-spec generates types only from typedef declarations,
ignoring structs, like "struct __uclibc_locale_struct;" in uClibc_locale.h.
This simple change allows to build libgo fine:
--- uClibc_locale.h.orig 2017-09-25 19:49:38.000000000 +0000
+++ uClibc_locale.h 2017-09-28 07:27:14.035517712 +0000
@@ -73,6 +73,7 @@
*/
struct __uclibc_locale_struct;
+typedef struct __uclibc_locale_struct __uclibc_locale_struct;
typedef struct __uclibc_locale_struct *__locale_t;
#endif /* !defined(__LOCALE_C_ONLY) */
Does this change look sane? Or should I patch GCC libgo/sysinfo.c instead
to add "typedef struct __uclibc_locale_struct __uclibc_locale_struct;"
there?
Thanks,
Alex