linux-kernel - [patch] fix for module building without "." in PATH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20101027162422.226590@gmx.net>
Date:	Wed, 27 Oct 2010 18:24:22 +0200
From:	"Alexander Stohr" <Alexander.Stohr@....de>
To:	linux-kernel@...r.kernel.org
Subject: [patch] fix for module building without "." in PATH

Hello,

when trying to build a kernel module remotely from the main sources
i run into a problem in a setup where the local directory was not part
of the path variable in the calling shell. this lead to the situation
that tools like fixdep worked fine whilst modpost steadily did not run
in a very silent fashion even if execv returned -1 (seen with strace).

i had two not that similar processor and linux systems to my hands
where one just ran fine for the given build duty and the other was
not at all capable of doing the job. the faulty had GNU make 3.81 on it.

the things went stranger the more i tried to reproduce the problem.
in a makefile sandbox a relative path like test/tool worked always nice
whilst in the kbuild environment scripts/mod/modpost always silently failed.

my next best answer to the subject was this:
-> completing the tool path using an absolute path prefix

asking which is the right path drove me to the insight
that it could be either the objtree or srctree that is desired.
my decision was a short shell invocation that determines
if the existing objtree does offer that build tool
and if not a fallback to the srctree is performed.

i think that best reflects the normal use case
where the object tree contains target build specific programs and data
whilst its a good idea to share all shareable tools via the srctree.

see the attached patch - its only one "-" and two "+" lines big.

it might be systematically helpful e.g. for distributions that are
building several different sets of binaries from the very same source
and its probably nice to have for smaller sized embedded platforms.

regards, Alex.

appendix

what else can that case teach us?

there are many more tools i have not adressed as they did not choke.
as this single case showed dot-less and dotted relative paths might
not always work in cases where PATH is missing the dot in its listing.

current state of root problem tracking and understanding:

i did not catch the reasons why those relative path without a leading dot
was inoperable in my setup for that changed makefile - the chain of
makefiles leading up to the failure seemed a bit lengthy so i simply
abstained from digging into more details. at least i was not able to
track down any sort of switches in make or the set of shells had to
my hand (bash, busybox) impacting on relative paths with/without dots.

guesswork:

maybe it has something to do with platform specific "empty path" variables (explicitely beeing a posix platform "feature") or make's path handling.

-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

View attachment "linux-next-20101027-abspath-modpost.patch" of type "text/x-patch" (648 bytes)