Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "André Draszik" <git@andred.net>
To: Khem Raj <raj.khem@gmail.com>, "Burton, Ross" <ross.burton@intel.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 4/4] uclibc: really enable verbose compilation
Date: Fri, 24 Jun 2016 15:19:39 +0100	[thread overview]
Message-ID: <1466777979.30669.6.camel@andred.net> (raw)
In-Reply-To: <CAMKF1spjUmGWxmS_+inmTCecFLQtbwQ5Pj=LAzsarA5_ymO4CQ@mail.gmail.com>

Hi Khem,

On Fr, 2016-06-24 at 06:57 -0700, Khem Raj wrote:
> make V=2
> 
>   CC ldso/ldso/ldso.oS -DNDEBUG -DNOT_IN_libc -DIS_IN_rtld
> -DUCLIBC_RUNTIME_PREFIX="/usr/x86_64-linux-uclibc/"
> -DUCLIBC_LDSO="ld64-uClibc.so.1" -DIN_LIB=rtld -DSHARED
> -DLDSO_ELFINTERP="x86_64/elfinterp.c"
> 
> make V=1
> 
> gcc -c ldso/ldso/ldso.c -o /tmp/uu/ldso/ldso/ldso.oS -Wall
> -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin
> -fno-asm -fmerge-all-constants -std=gnu99 -fno-stack-protector
> -nostdinc -I/tmp/uu/include -I./include -include libc-symbols.h
> -I./libc/sysdeps/linux/x86_64 -I./libc/sysdeps/linux
> -I./ldso/ldso/x86_64 -I./ldso/include -I. -Os -fstrict-aliasing
> -I./libc/sysdeps/linux/common -isystem
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed -isystem
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include -I/ -DNDEBUG
> -DNOT_IN_libc -DIS_IN_rtld -fno-stack-protector
> -fno-omit-frame-pointer -I./ldso/ldso/x86_64 -I./ldso/include
> -I./ldso/ldso -DUCLIBC_RUNTIME_PREFIX=\"/usr/x86_64-linux-uclibc/\"
> -DUCLIBC_LDSO=\"ld64-uClibc.so.1\" -DIN_LIB=rtld -fPIC -DSHARED
> -DLDSO_ELFINTERP=\"x86_64/elfinterp.c\" -MT /tmp/uu/ldso/ldso/ldso.oS
> -MD -MP -MF /tmp/uu/ldso/ldso/.ldso.oS.dep
> 
> So it must be local issue.

Well exactly, V=1 gives more verbose output than V=2 :-)

One of the reasons this is useful is that with V=1 one can now simply
copy/paste the command line and modify it for test purposes. In addition,
you can easily verify that everything is on the command line as expected.

make V=2

  CC libc/sysdeps/linux/common/execve.os -D__USE_STDIO_FUTEXES__
-DHAVE_FORCED_UNWIND -D_LIBC_REENTRANT -DNDEBUG -DIN_LIB=libc


vs.

make V=1

mipsel-poky-linux-uclibc-gcc  -mel -mabi=32 -msoft-float -march=mips32r2
-mno-mips16  -minterlink-compressed -mtune=24kec -mdsp --sysroot=<sysroot1>
-c libc/sysdeps/linux/common/execve.c -o libc/sysdeps/linux/common/execve.os
-Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin
-fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -mabi=32 -fno-stack-
protector -nostdinc -I./include -I./include -include libc-symbols.h
-I./libc/sysdeps/linux/mips -I./libc/sysdeps/linux -I./ldso/ldso/mips
-I./ldso/include -I. -Os -fstrict-aliasing -mno-split-addresses -O2 -pipe -g
-feliminate-unused-debug-types -fdebug-prefix-
map=<map1>=/usr/src/debug/uclibc/1.0.15+gitAUTOINC+95174cb69c-r0 -fdebug-
prefix-map=<map2>= -fdebug-prefix-map=<map3>= -D__USE_STDIO_FUTEXES__
-DHAVE_FORCED_UNWIND -D_LIBC_REENTRANT -I./libpthread/nptl
-I./libpthread/nptl -I./libpthread/nptl/sysdeps/unix/sysv/linux/mips
-I./libpthread/nptl/sysdeps/mips -I./libpthread/nptl/sysdeps/mips
-I./libpthread/nptl/sysdeps/unix/sysv/linux
-I./libpthread/nptl/sysdeps/unix/sysv/linux
-I./libpthread/nptl/sysdeps/pthread -I./libpthread/nptl/sysdeps/pthread/bits
-I./libpthread/nptl/sysdeps/generic -I./libc/sysdeps/linux/common -isystem
<...>/x86_64-linux/usr/lib/mipsel-poky-linux-uclibc.gcc-cross-initial-
mipsel/gcc/mipsel-poky-linux-uclibc/6.1.1/include-fixed -isystem .../x86_64-
linux/usr/lib/mipsel-poky-linux-uclibc.gcc-cross-initial-mipsel/gcc/mipsel-
poky-linux-uclibc/6.1.1/include -I.../usr/include/ -DNDEBUG -DIN_LIB=libc
-fPIC -MT libc/sysdeps/linux/common/execve.os -MD -MP -MF
libc/sysdeps/linux/common/.execve.os.dep


I honestly think the latter to be more useful...


Cheers,
Andre'



  reply	other threads:[~2016-06-24 14:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 10:54 [PATCH 1/4] libidn: fix QA warning (uClibc) André Draszik
2016-06-24 10:54 ` [PATCH 2/4] json-c: backport patch to fix uClibc link issues André Draszik
2016-06-24 10:54 ` [PATCH 3/4] uclibc: backport patch to fix gdb 7.11 compilation André Draszik
2016-06-24 13:52   ` Khem Raj
2016-06-24 14:39   ` [PATCH 3/4 v2] " André Draszik
2016-06-24 10:54 ` [PATCH 4/4] uclibc: really enable verbose compilation André Draszik
2016-06-24 13:46   ` Khem Raj
2016-06-24 13:51     ` Burton, Ross
2016-06-24 13:57       ` Khem Raj
2016-06-24 14:19         ` André Draszik [this message]
2016-06-24 14:32           ` André Draszik
2016-06-24 14:59           ` Khem Raj
2016-06-24 15:30   ` [PATCH 4/4 v2] uclibc: re-enable " André Draszik

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=1466777979.30669.6.camel@andred.net \
    --to=git@andred.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=ross.burton@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox