Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'DT_CHR' undeclared when compiling print3d #45

Open
companje opened this issue May 8, 2016 · 7 comments
Open

'DT_CHR' undeclared when compiling print3d #45

companje opened this issue May 8, 2016 · 7 comments

Comments

@companje
Copy link
Member

companje commented May 8, 2016

When compiling print3d on OSX (without Docker) I get the error below. I think the #define __USE_BSD is not sufficient on OSX to let the #include <dirent.h> define DT_CHR which has the value 2. As a workaround I added #define DT_CHR 2 to ipc_shared.c. That seems to work.

[  9%] Building C object CMakeFiles/ipc_shared.dir/ipc_shared.c.o
/Volumes/OpenWrt/openwrt/build_dir/target-mips_34kc_musl-1.1.14/print3d/ipc_shared.c: In function 'ipc_find_devices':
/Volumes/OpenWrt/openwrt/build_dir/target-mips_34kc_musl-1.1.14/print3d/ipc_shared.c:112:23: error: 'DT_CHR' undeclared (first use in this function)
    if (ent->d_type == DT_CHR && strncmp(ent->d_name, name, strlen(name)) == 0) {
                       ^
/Volumes/OpenWrt/openwrt/build_dir/target-mips_34kc_musl-1.1.14/print3d/ipc_shared.c:112:23: note: each undeclared identifier is reported only once for each function it appears in
make[5]: *** [CMakeFiles/ipc_shared.dir/ipc_shared.c.o] Error 1
make[4]: *** [CMakeFiles/ipc_shared.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [/Volumes/OpenWrt/openwrt/build_dir/target-mips_34kc_musl-1.1.14/print3d/.built] Error 2
make[2]: Leaving directory `/Volumes/OpenWrt/openwrt/customfeeds/print3d'
make[1]: *** [package/feeds/customfeeds/print3d/compile] Error 2
make[1]: Leaving directory `/Volumes/OpenWrt/openwrt'
make: *** [package/print3d/compile] Error 2
@woutgg
Copy link
Contributor

woutgg commented May 10, 2016

It looks like you were running a cross-build, with uClibc replaced by musl.
The __USE_BSD define is specifically intended for uClibc (see here).
A similar trick can be used for musl, for example by defining _BSD_SOURCE, see here.

@companje
Copy link
Member Author

Ah, that makes sense. Thanks Wouter. I'm not sure how I ended up with musl but I guess it's a good choice for they experiment I'm working on. Can you elaborate a bit about the differences and pros and cons?

@woutgg
Copy link
Contributor

woutgg commented May 10, 2016

Oh I wouldn't know about that. I only learned about its existence because I noticed it in your compilation log instead of the usual uclibc. :)

While I was looking for info though, I did find a comparison table on their website.
As far as I can discern linking against musl yields smaller files (e.g. 13kB vs 70kB for a static hello world binary), I could imagine this adding up to a significant amount over all binaries, but I cannot tell for sure of course.
Apart from that, it seems to be somewhat faster (no idea if that will be noticeable) and is a bit more feature-rich in general (or rather: more green boxes for musl than for uclibc in the table).

If we can build an image with musl without too much trouble, we could have a quick look at how they compare in practice, just for fun and profit.

@woutgg
Copy link
Contributor

woutgg commented May 10, 2016

I don't know atm which revision of OpenWRT we are currently building with, but this might explain the unexpected use of musl Rick encountered: http://comments.gmane.org/gmane.comp.embedded.openwrt.devel/32651.

@peteruithoven
Copy link
Member

@woutgg
Copy link
Contributor

woutgg commented May 10, 2016

I see. Perhaps the choice is fixed in our .config, here. If that is true, Rick probably created a new config when building an image?

@olijf
Copy link
Contributor

olijf commented May 12, 2016

@woutgg I did a little test to see about the size difference and noticed some binaries being smaller... I havent tested the current trunk with our wifibox packages but I am planning on doing so to see if we can switch.
As MUSL is the norm in the current trunk (and latest stable) I recommend switching to ensure compatibility.
BTW rick wanted to build a small package (https://github.com/companje/up3dload) to use the UP3D printer on the wifibox.

On a side note: packages build with MUSL are not compatible with current Wifibox builds as 14.07 uses uClib to build everything you can not install those packages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants