|
|
Subscribe / Log in / New account

Quote of the week

Our build system is good, but it's good as in "clever and complex" rather than necessarily good as in "very secure".

So anybody who builds the kernel as root is doing something seriously wrong, in my opinion.

Linus Torvalds

to post comments

Quote of the week

Posted Apr 25, 2019 15:02 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

I tried introducing a fail-when-built-as-root to a particularly hairy part of (our enterprise) kernel build once. It turned out that basically everyone was building as root, and they were mostly quite angry that I'd broken their build... I still think building as root should be outright prohibited, and Libtool should be fixed to not run the linker as root when doing make installs of dependent libraries, too. Eventually perhaps we can make the gcc compiler drivers refuse to run as root, dammit, and the world will be a little bit safer.

(I note that Meson has added more madness here: it runs gtk-doc, which means xsltproc and God knows what else, as root...)

Quote of the week

Posted Apr 25, 2019 15:26 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> (I note that Meson has added more madness here: it runs gtk-doc, which means xsltproc and God knows what else, as root...)

Is that really Meson's fault or is it more on the GTK Meson input rules that are only attached to the `install` target? Granted, running ninja itself has some issues as root[1]. However, personally, I almost never do a `sudo make install` anyways since I install software like ports into my home directory (and it needs added to PATH and friends manually). The system is managed by the package manager. I manage my home directory.

[1]https://github.com/ninja-build/ninja/issues/1302

Quote of the week

Posted Apr 26, 2019 11:48 UTC (Fri) by nix (subscriber, #2304) [Link]

Is that really Meson's fault or is it more on the GTK Meson input rules that are only attached to the `install` target?
Oh, almost certainly the latter -- but last I checked this stuff was managed by a plugin that was actually part of the Meson source tree, so it's Meson's doing in any case. :)
However, personally, I almost never do a `sudo make install` anyways since I install software like ports into my home directory (and it needs added to PATH and friends manually). The system is managed by the package manager. I manage my home directory.
Even if you're using a package manager, you should still be doing make install DESTDIR=... as non-root and doing a final, non-customizable-by-the-package-itself install phase of some kind as root (rpm installation, grafting, stowing, whatever, and the usual rebuilding of systemwide caches like fontconfig, mime-install, ldconfig etc as needed). However, this can lead to extra complexity and the need for either per-package customization work or some sort of LD_PRELOAD interposer like fakeroot if make install installs things with unusual ownerships or permissions, as some still do.

And things like CPAN.pm and pip and gem make this even harder :/

libtool and root

Posted Apr 27, 2019 21:37 UTC (Sat) by ballombe (subscriber, #9523) [Link] (1 responses)

There is an issue with darwin compatibility: darwin ignores rpath and instead uses the path to the library on the command line at link time. So to avoid this issue, some Makefiles first install the library and then relink the binary with the installed library. Usually as root.

libtool and root

Posted Apr 29, 2019 13:20 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

It doesn't care about the command line name given to the library. Each library has an ID which is how it should be looked up. Usually this is done with `@rpath/`, but this requires that *consumers* add the proper LC_RPATH entries to the consuming libraries otherwise it cannot be found. Note that LC_RPATH is ignored is @rpath/ is not used (e.g., absolute path, @executable_path/, or @loader_path/ each of which has its uses). And relinking is not required; install_name_tool can edit the files in-place before or after installation (provided -header_max_path or whatever flag was passed to ensure you have enough space to actually edit the library).

Quote of the week

Posted Apr 25, 2019 20:14 UTC (Thu) by flussence (guest, #85566) [Link] (3 responses)

Quick primer for anyone not familiar with building the kernel the Right Way™:

make -C [SRCDIR] O=[DESTDIR] [TARGET]

where -

  • SRCDIR is the kernel source tree, usually /usr/src/linux;
  • DESTDIR needs to be a writable directory (e.g. ~/kbuild; will be created if missing);
  • TARGET can be any of the make targets that create files (e.g. oldconfig).

After running this line (it only needs to be done once), DESTDIR will contain a proxy Makefile that recognises all the usual kernel commands, and you can build a kernel in there as an unprivileged user. If you set the KBUILD_OUTPUT env var to point to this location, you can even convince your package manager to build out-of-tree modules against it — all while having no write access to the source or object directories.

It seems easy once you know it's there, but the hardest part is to go from not knowing to knowing. The help output does mention make O=dir but it's not obvious that that's the magic word.

Quote of the week

Posted May 25, 2019 7:23 UTC (Sat) by mcortese (guest, #52099) [Link] (1 responses)

I've always thought that the Right Way was

$ cd where/the/kernel/source/is
$ make TARGET

Never used -C or O=

Perhaps you are trying to address a special case, like keeping the source in a central root-owned dir but allowing non-root users to compile their version?

Quote of the week

Posted May 25, 2019 15:34 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

I always try to do out-of-source builds where possible. It allows me to move build trees to a separate partition, exclude them from backups, and I can have multiple configurations of a source tree built without having to start from scratch when switching between them.

Quote of the week

Posted May 26, 2019 0:59 UTC (Sun) by pabs (subscriber, #43278) [Link]

Another option that worked for me and seems to do the same thing as your command:

make -f /usr/src/linux/Makefile


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds