All of lore.kernel.org
 help / color / mirror / Atom feed
* uclibc.inc oddities
@ 2009-06-10 14:55 Phil Blundell
  0 siblings, 0 replies; only message in thread
From: Phil Blundell @ 2009-06-10 14:55 UTC (permalink / raw)
  To: openembedded-devel

I discovered the following fragment in uclibc.inc:

# do_stage barfs on a CC with whitepspace, therefore put the
'HOST_CC_ARCH' in
# the CFLAGS (for when building the utils).
OEMAKE_NO_CC = "'STRIPTOOL=true' 'LD=${LD}' \
		'LOCALE_DATA_FILENAME=${UCLIBC_LOCALE_FILE}'"
EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}' \
		'HOSTCFLAGS=-I${STAGING_INCDIR_NATIVE}'"
EXTRA_OEMAKE_task_do_package = "${OEMAKE_NO_CC}"
EXTRA_OEMAKE_task_do_populate_staging = "${OEMAKE_NO_CC}"

The intent seems to be to avoid passing ${CC} to do_package or do_stage
in order to work around what I guess is a build system limitation.
However, this is breaking uclibc-initial for me because of a second
quirk, namely that this recipe has a blank do_compile() and builds
everything inside do_stage():

do_stage() {
	# Install initial headers into the cross dir
	oe_runmake V=1 PREFIX= DEVEL_PREFIX=${UCLIBC_STAGE_PREFIX}/ \
		RUNTIME_PREFIX=${UCLIBC_STAGE_PREFIX}/ \
		pregen install_dev
	oe_runmake V=1 PREFIX= DEVEL_PREFIX=${UCLIBC_STAGE_PREFIX}/ \
		RUNTIME_PREFIX=${UCLIBC_STAGE_PREFIX}/ \
		lib/crt1.o lib/crti.o lib/crtn.o

	install -d ${CROSS_DIR}/${TARGET_SYS}	
	ln -sf include ${CROSS_DIR}/${TARGET_SYS}/sys-include

	# This conflicts with the c++ version of this header
	rm -f ${UCLIBC_STAGE_PREFIX}/include/bits/atomicity.h
	install -m 644 lib/crt[1in].o ${UCLIBC_STAGE_PREFIX}/lib
	${CC} -nostdlib -nostartfiles -shared -x c /dev/null \
		-o ${UCLIBC_STAGE_PREFIX}/lib/libc.so

}

In my configuration, ${CC} contains some flags that are required for
correct compilation: trying to build without them just results in a
final link failure.

Deleting the assignment to EXTRA_OEMAKE_task_do_populate_staging allows
my uclibc-initial build to succeed, and doesn't seem to have introduced
any other obvious problems.  However, since I'm not sure exactly what
the original problem was that this code was trying to avoid, I can't
tell whether reinstating ${CC} is going to cause trouble for some other
configuration.

I'm also not entirely sure whether the behaviour of uclibc-initial is
deliberate, or whether this "compile the entire library inside do_stage"
thing has been introduced by mistake.

Can anybody shed any light on either of those two issues?

thanks

p.





^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2009-06-10 15:05 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-10 14:55 uclibc.inc oddities Phil Blundell

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.