nix builds with the changes here.
1 Like
What's your feeling on strategically including certain constants which are not in uclibc but are likely supported by the kernel? I'm thinking specifically of the open(2) flag O_TMPFILE, which has been in linux since 3.11, but isn't currently defined in uclibc. The lack of this symbol will prevent certain crates (like the popular tempfile) from compiling.
Honestly, I'm not that well versed in low level linux/kernel. My sole merit is that I managed to build the rust compiler for this target. That said, if the target is called armv7-unknown-linux-uclibceabihf, then I'm thinking, like all other <arch>-<vendor>-linux-<libc impl> targets, it should include the bindings found in the /unix/mod.rs file, the /unix/linux_like/mod.rs and also the /unix/linux_like/linux/mod.rs file. Since O_TMPFILE is provided by the kernel, isn't this flag present in one of the files mentioned above? If it is, then I'm thinking your PR would enable its presence. I'm still not clear why uclibc was not alongside musl and gnu in libc though. I'm waiting for one of the maintainers to leave a comment on your PR so we can find out. Also, I've heard that uclibc is highly configurable, which kind of throws a wrench into rust's libc since some minimal configurations might be missing pieces that are expected to exist in libc. Sorry for not being able to give you a better answer.
P.S. Here's a presentation of uclibc that helped me a little bit, hopefully it will help you as well.
After a quick search I found the O_TMPFILE flag in the src/unix/uclibc/arm/mod.rs file. Then I noticed it's missing in your branch where you moved uclibc under linux. Are you sure you moved everything correctly?
Are you sure you moved everything correctly?
Yes, in that if you build the following in uclibc it won't compile:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(void) {
return open("/tmp/thing", O_TMPFILE);
}
./main.c: In function ‘main’:
./main.c:5:31: error: ‘O_TMPFILE’ undeclared (first use in this function)
5 | return open("/tmp/thing", O_TMPFILE);
| ^~~~~~~~~
./main.c:5:31: note: each undeclared identifier is reported only once for each function it appears in
The same code compiles perfectly fine with glibc.
As it happens uclibc appears to just pass the flag through to the kernel but there's no guarantee that it must be so. So by leaving that constant in place, we'd be encoding the assumption that the kernel will understand (or suitably reject) the flag, and that no future uclibc will interfere with the mechanism via some change in their implementation of open().
I think it's a reasonable assumption, especially since that kernel interface would be very unlikely to change, but it is, strictly speaking, not part of the uclibc API.
That is true, and I tried to take a very permissive view of my libc implementation, and tried to support everything which uclibc might support. If someone made use of a feature which was not supported by their build of uclibc, they'd end up with a linker error (for missing symbols) or a runtime error (for unsupported constants). There are several other examples of this in libc (outside of the ucilbc work) so I'm confident in the approach.
1 Like
Hurray! It seems like we have one more contributor to this target. Here is a pull request from ykoehler
Nice!
@tsidea I'm working on getting that libc pull request through. The request has been made for me to enable builds of uclibc target(s) in libc's CI. Do you know of a source for a precompiled gcc for this target? I would normally look at openwrt but it seems to all be based on musl now.
@skrap I don't have a location for a prebuilt gcc cross-compiler with uclibc. I've seen a project that uses buildroot and the linaro gcc binary to create a toolchain. I think I could come up with the commands to have buildroot create a toolchain for uclibc. Would that work for you?
Thanks for the offer. Using buildroot was my next step, but I think I can handle it. We'll see if the maintainers actually want that 
Just replying to myself here that I am still pursuing the uclibc reorganization in the libc crate, and it seems likely to be accepted soon. Also, I have found that bootlin has lots of exciting prebuilt toolchains, including this architecture, at https://toolchains.bootlin.com/
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.