Build: Compile with dietlibc (dependency-free)

[am11]

(Based on @aredridel's suggestions via IRC channel)

With @mgreter's help, we are able to succeed in building cross-distribution binaries: sass/node-sass#517. But undoubtedly, that was a painful process, as eventually we had to alter to code to build with GCC 4.4.7 and glibc 2.12. Moving forward, this might not be feasible solution (to change the code each time before the release).

Here is one proposal to make the libsass build promising (which we may consume as is -- compiled form -- via node-sass).

Using dietlibc:

If libsass incorporates dietlibc (instead of OOTB glibc) in its build script; Makefile (CC = "diet gcc -nostdinc", more info here), we can deliver an unbiased, dependency-free libsass binary for Linux, ready to distribute to masses! With that, we will set our binding.gyp, to produce the Makefile with similar configurations.

Points to ponder:

- Since libsass consumes both C and C++ features, would dietlib suffice to render it dependency-free? - Would this also help in future plans for distro package (https://github.com//issues/757) and libsass.so.\* releases?

Footnote: I am able to compile libsass with dietlibc, but ldd shows libc.so.6 as dependency (hence a failed attempt?)

[QuLogic]

Since dietlibc is a C standard library replacement, I don't think it implements anything in the C++ standard library...

[QuLogic]

Also, you should remember to use dietlibc when linking, which doesn't work for me. Either you mix the two:

cc -O2  -o bin/sassc sassc.o /home/elliott/code/libsass/lib/libsass.a -lstdc++ -lm
sassc.o:(.note+0x10): undefined reference to `__you_tried_to_link_a_dietlibc_object_against_glibc'
/home/elliott/code/libsass/lib/libsass.a(cencode.o):(.note+0x10): undefined reference to `__you_tried_to_link_a_dietlibc_object_against_glibc'

Or it fails because there's no C++ library:

~/code/dietlibc-0.33/bin-x86_64/diet gcc -O2  -o bin/sassc sassc.o /home/elliott/code/libsass/lib/libsass.a -lstdc++ -lm
/usr/bin/ld: cannot find -lstdc++
/home/elliott/code/libsass/lib/libsass.a(json.o): In function `emit_string(SB*, char const*)':
json.cpp:(.text+0x5f6): warning: warning: your code still has assertions enabled!
/home/elliott/code/dietlibc-0.33/bin-x86_64/dietlibc.a(sprintf.o): In function `sprintf':
sprintf.c:(.text+0x83): warning: warning: Avoid *sprintf; use *snprintf. It is more secure.
/home/elliott/code/dietlibc-0.33/bin-x86_64/dietlibc.a(vsnprintf.o): In function `vsnprintf':
vsnprintf.c:(.text+0x8d): warning: warning: the printf functions add several kilobytes of bloat.
/home/elliott/code/dietlibc-0.33/bin-x86_64/dietlibc.a(stderr.o): In function `__fflush_stderr':
stderr.c:(.text+0x8): warning: warning: your code uses stdio (7+k bloat).
collect2: error: ld returned 1 exit status
Makefile:35: recipe for target 'build-static' failed

Distro packages would be built against the standard libraries in the distro, so using dietlibc would have no benefit there. Most distros would not want you bundling things, so it'd be more work to take it out instead.

[am11]

Hi @QuLogic. Thanks for the info! 👍

I don't think it implements anything in the C++ standard library...

This makes perfect sense. I was afraid of the same thing. :)

But according to ldd, part of the dynamic lib depends on GLIBC (which is one of two issues described here: sass/node-sass#517). Wouldn't using dietlibc fix the libc dependency bit?

For distro releases I agree, it would make more sense to compile against the standard libc.

[mgreter]

I don't think this is something we want to include in our build scripts. But I also don't see the actual problem. Is there a problem when building with autotools? If you like you may add a chapter to the Building Wiki about how to build libsass against dietlibc, but I do not really see the reason for this, as IMO libstdc++ will also require libstdc:

ldd /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6

linux-vdso.so.1
libm.so.6 => /lib64/libm.so.6
libc.so.6 => /lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1

[QuLogic]

dietlibc is a replacement mostly for memory-constrained systems; I'm not sure I'd call it a fix, per se.

But I agree with @mgreter; I'm not sure there's any need to be putting anything in libsass itself. You could just set the CC and CXX variables when you compile, if you really need it (and if it actually worked ;).

[am11]

True. I think we should stick with the current approach: compile our binding with oldest GCC and Glibc, which does not require altering the libsass code. That is probably GCC 4.5.4 and GlibC 2.12. :)

Thanks for curing my curiosity! 😃 👍