Macros __attribute__, __format__ and __printf__ are defined in argp.h
for compatibility with ANSI and old gccs. But leaving them effective
out of the scope of the header may break applications relying on
these compiler attributes even with __STRICT_ANSI__ defined. So undef
the macros after using.
---
include/argp.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/argp.h b/include/argp.h
index 8e8674296..1824c69d6 100644
--- a/include/argp.h
+++ b/include/argp.h
@@ -562,4 +562,14 @@ __NTH (__option_is_end (__const struct argp_option *__opt))
}
#endif
+#ifdef __attribute__
+# if __GNUC__ < 2 ||(__GNUC__ == 2 && __GNUC_MINOR__ < 5) || defined(__STRICT_ANSI__)
+# undef __attribute__
+# endif
+# if __GNUC__ < 2 ||(__GNUC__ == 2 && __GNUC_MINOR__ < 7) || defined(__STRICT_ANSI__)
+# undef __format__
+# undef __printf__
+# endif
+#endif
+
#endif /* argp.h */
--
2.43.0
Hi,
I released a new version of uClibc-ng today.
A lot of bugfixing for riscv32/riscv64 were done.
Riscv32 is now fully supported. Riscv64 C++ applications are working
now.
Also explicit_bzero and reallocarray were added from musl libc.
This time big thanks go to sorear for fixing all the riscv problems.
Have fun,
Waldemar
Hello there!
After successfuly building my OpenADK image and launching into an mksh shell, I noticed that some programs behaved very, very weirdly. Especially in terms of time.
For instance, take this `ps` (coreutils) output:
# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 99 Mar02 pts/0 1158050441-07:00:15 /bin/mksh -il
root 40 1 99 Mar02 pts/0 1158050441-07:00:15 ps -ef
It never changes, ever. However, `date` reports the time correctly:
root@d6571a5cd187:/ # date "+%s"
1709916714
But Git and even GCC all hang and behave weirdly. Git can't even fetch a basic repo, because it believes the time in the index to be totally wrong.
Do you have an idea what this is caused by?
And yes, I did change my timezone with the TZ environment variable, too:
root@d6571a5cd187:/ # export TZ="Europe/Berlin"
root@d6571a5cd187:/ # date "+%s"
1709916972
root@d6571a5cd187:/ # ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 99 Mar02 pts/0 1158050441-07:00:15 /bin/mksh -il
root 42 1 99 Mar02 pts/0 1158050441-07:00:15 ps -ef
The container runs with --previleged, so I thought to just change the time:
root@d6571a5cd187:/ # ntpclient -h ptbtime1.ptb.de -s
45357 61036.066 22575.0 24.0 -16383.9 15.3 4056424
root@d6571a5cd187:/ # ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 99 Mar02 pts/0 1158050441-07:00:15 /bin/mksh -il
root 44 1 99 Mar02 pts/0 1158050441-07:00:15 ps -ef
My only lead is that part of the time is wrong...
I attached my OpenADK and Kernel config, and even extracted the generated uClibc-ng config from the build too (well, from the toolchain build).
Also, I did try to just mount the /etc files into the container as well, but that did not help apparently.
Any idea what's going wrong here or how I could debug this? Thanks!
Kind regards,
Ingwie
I have an ARM9 platform that's running a pretty old Linux kernel
(2.6.33.7 built with GCC 4.6.3). It's currently using a buildroot
user-space built with that same compiler and uClibc 0.9.30.
Moving to a newer kernel is not an option because of performance
issues. Using a significantly newer version of GCC to build the
kernel would also require more than a little kernel hacking. So I
probably have to stick with the existing kernel build.
For various reasons, updating to recent versions of a few user-space
packages might be required. Are there likely to be compatibility
problems building/running a user-space (e.g. with buildroot) using a
recent toolchain (gcc 12.3, uClib-ng 1.0.45) for user-space and a
kernel that old?
--
Grant
Hello there!
Apologies if this is going into the wrong list, but I honestly was n't sure,e specially since this very issue was discussed a long time ago - found an exchange about this in the archive through Google - so I ended up just posting it here.
I am currently building a toolset for RISC-V to use as a rootfs for a Docker Container that can then be used as a Jenkins agent to eventually build my way through Alpine's abuild/aports, so that I can reconstruct the alpine:3.19 image, but for RISC-V (there are only snapshots and the :edge image, right now).
Most things built just fine; kernel, toolchain and alike. But when it tries to configure libatomic for the target, this happens:
configure:14906: riscv64-openadk-linux-uclibc-cc -o conftest -g -O2 -g -Os -fno-sync-libcalls -pthread conftest.c >&5/nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/../../../../riscv64-openadk-linux-uclibc/bin/ld: /nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/libgcc.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE':
(.text+0x1adc): undefined reference to `dl_iterate_phdr'
collect2: error: ld returned 1 exit status
configure:14906: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Atomic Library"
| #define PACKAGE_TARNAME "libatomic"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU Atomic Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libatomic/"
| #define PACKAGE "libatomic"
| #define VERSION "1.0"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define LT_OBJDIR ".libs/"
| #define IFUNC_RESOLVER_ARGS void
| #define STDC_HEADERS 1
| #define STRING_WITH_STRINGS 1
| #define HAVE_INT1 1
| #define HAVE_INT2 1
| #define HAVE_INT4 1
| #define HAVE_INT8 1
| #define HAVE_INT16 1
| #define HAVE_ATOMIC_LDST_1 1
| #define HAVE_ATOMIC_LDST_2 1
| #define HAVE_ATOMIC_LDST_4 1
| #define HAVE_ATOMIC_LDST_8 1
| #define HAVE_ATOMIC_LDST_16 0
| #define HAVE_ATOMIC_TAS_1 1
| #define HAVE_ATOMIC_TAS_2 1
| #define HAVE_ATOMIC_TAS_4 1
| #define HAVE_ATOMIC_TAS_8 1
| #define HAVE_ATOMIC_TAS_16 1
| #define HAVE_ATOMIC_EXCHANGE_1 1
| #define HAVE_ATOMIC_EXCHANGE_2 1
| #define HAVE_ATOMIC_EXCHANGE_4 1
| #define HAVE_ATOMIC_EXCHANGE_8 1
| #define HAVE_ATOMIC_EXCHANGE_16 0
| #define HAVE_ATOMIC_CAS_1 1
| #define HAVE_ATOMIC_CAS_2 1
| #define HAVE_ATOMIC_CAS_4 1
| #define HAVE_ATOMIC_CAS_8 1
| #define HAVE_ATOMIC_CAS_16 0
| #define HAVE_ATOMIC_FETCH_ADD_1 1
| #define HAVE_ATOMIC_FETCH_ADD_2 1
| #define HAVE_ATOMIC_FETCH_ADD_4 1
| #define HAVE_ATOMIC_FETCH_ADD_8 1
| #define HAVE_ATOMIC_FETCH_ADD_16 0
| #define HAVE_ATOMIC_FETCH_OP_1 1
| #define HAVE_ATOMIC_FETCH_OP_2 1
| #define HAVE_ATOMIC_FETCH_OP_4 1
| #define HAVE_ATOMIC_FETCH_OP_8 1
| #define HAVE_ATOMIC_FETCH_OP_16 0
| #define WORDSIZE 8
| /* end confdefs.h. */
| #include <pthread.h>
| void *g(void *d) { return NULL; }
| int
| main ()
| {
| pthread_t t; pthread_create(&t,NULL,g,NULL);
| ;
| return 0;
| }
configure:14922: riscv64-openadk-linux-uclibc-cc -o conftest -g -O2 -g -Os conftest.c -lpthread >&5
/nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/../../../../riscv64-openadk-linux-uclibc/bin/ld: /nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/libgcc.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE':
(.text+0x1adc): undefined reference to `dl_iterate_phdr'
collect2: error: ld returned 1 exit status
configure:14922: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Atomic Library"
| #define PACKAGE_TARNAME "libatomic"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU Atomic Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libatomic/"
| #define PACKAGE "libatomic"
| #define VERSION "1.0"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define LT_OBJDIR ".libs/"
| #define IFUNC_RESOLVER_ARGS void
| #define STDC_HEADERS 1
| #define STRING_WITH_STRINGS 1
| #define HAVE_INT1 1
| #define HAVE_INT2 1
| #define HAVE_INT4 1
| #define HAVE_INT8 1
| #define HAVE_INT16 1
| #define HAVE_ATOMIC_LDST_1 1
| #define HAVE_ATOMIC_LDST_2 1
| #define HAVE_ATOMIC_LDST_4 1
| #define HAVE_ATOMIC_LDST_8 1
| #define HAVE_ATOMIC_LDST_16 0
| #define HAVE_ATOMIC_TAS_1 1
| #define HAVE_ATOMIC_TAS_2 1
| #define HAVE_ATOMIC_TAS_4 1
| #define HAVE_ATOMIC_TAS_8 1
| #define HAVE_ATOMIC_TAS_16 1
| #define HAVE_ATOMIC_EXCHANGE_1 1
| #define HAVE_ATOMIC_EXCHANGE_2 1
| #define HAVE_ATOMIC_EXCHANGE_4 1
| #define HAVE_ATOMIC_EXCHANGE_8 1
| #define HAVE_ATOMIC_EXCHANGE_16 0
| #define HAVE_ATOMIC_CAS_1 1
| #define HAVE_ATOMIC_CAS_2 1
| #define HAVE_ATOMIC_CAS_4 1
| #define HAVE_ATOMIC_CAS_8 1
| #define HAVE_ATOMIC_CAS_16 0
| #define HAVE_ATOMIC_FETCH_ADD_1 1
| #define HAVE_ATOMIC_FETCH_ADD_2 1
| #define HAVE_ATOMIC_FETCH_ADD_4 1
| #define HAVE_ATOMIC_FETCH_ADD_8 1
| #define HAVE_ATOMIC_FETCH_ADD_16 0
| #define HAVE_ATOMIC_FETCH_OP_1 1
| #define HAVE_ATOMIC_FETCH_OP_2 1
| #define HAVE_ATOMIC_FETCH_OP_4 1
| #define HAVE_ATOMIC_FETCH_OP_8 1
| #define HAVE_ATOMIC_FETCH_OP_16 0
| #define WORDSIZE 8
| /* end confdefs.h. */
| #include <pthread.h>
| void *g(void *d) { return NULL; }
| int
| main ()
| {
| pthread_t t; pthread_create(&t,NULL,g,NULL);
| ;
| return 0;
| }
configure:14925: error: Pthreads are required to build libatomic
I went and looked up what that function is, exactly, and learned quickly that this is caused by me having chosen a static build. That said, this was also already discussed: https://uclibc.uclibc.narkive.com/079V4ltx/dl-iterate-phdr-missing-in-libc
So, I am at a loss on what to do right now. I changed my setting to also build dynamic objects, then cleaned uClibc-ng and rebuilt and then attempted again to let the normal build run. But, that too, did not help.
My questions:
- Is dl_iterate_phdr in libc.a? According to grep, it matches, but that doesn-ät mean much.
- I am using the 1.0.46 version of uClibc as openADK selects that.
- Is there anything I can do to fix this, or do I have to start over and just build with shared libraries? I honestly would not be surprised if GCC just didn#t want to be statically linked; static is the devil, after all. ;)
Thanks and kind regards,
Ingwie
