From: Mike Crowe <mac@mcrowe.com>
To: buildroot@busybox.net
Subject: [Buildroot] Having MAKE set in environment causes buildroot to leak its own value
Date: Wed, 5 Aug 2009 14:55:02 +0100 [thread overview]
Message-ID: <20090805135502.GA16052@mcrowe.com> (raw)
Having just spent a while trying to fathom this I thought it
worthwhile documenting it if only to give people who find the same
problem something they can google for.
I saw problems when building openssl with BR2_JLEVEL set to anything
higher than 1:
asn1pars.o: In function `asn1parse_main':
asn1pars.c:(.text+0xe8): undefined reference to `OBJ_cleanup'
asn1pars.c:(.text+0x2d0): undefined reference to `OBJ_create_objects'
It was pretty clear that openssl was building parts of itself with
-j$(BR2_JLEVEL) even though the openssl.mk file specifically uses
$(MAKE1).
I discovered that the options set in the MAKE variable in
package/Makefile.in were leaking through to recursive makes that
openssl's Makefile launched. This only occurred if MAKE happened to be
set in the environment that launched buildroot's make[1]. Although
openssl's top level make is run linearly any sub-makes it spawns
receive -j$(BR2_jLEVEL) and run in parallel. :(
I worked around this by ensuring that MAKE was unset before launching
the buildroot build system.
Assuming my understanding is correct I wonder if it would be better to
fix this permanently by adding "unexport MAKE" to package/Makefile.in?
Alternatively would it be worth adding a check to
toolchain/dependencies/dependencies.sh?
Thanks.
Mike.
[1] In my case it was being set by our SoC supplier's build system
which wraps buildroot.
reply other threads:[~2009-08-05 13:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090805135502.GA16052@mcrowe.com \
--to=mac@mcrowe.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.