Re: cross compiling perf

[Milian Wolff <milian.wolff@kdab.com>]

[-- Attachment #1: Type: text/plain, Size: 5656 bytes --]

On Thursday, August 4, 2016 9:13:27 PM CEST Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 04, 2016 at 11:58:32PM +0200, Milian Wolff escreveu:
> > On Donnerstag, 4. August 2016 15:36:05 CEST Arnaldo Carvalho de Melo 
wrote:
> > > Em Thu, Aug 04, 2016 at 05:02:01PM +0200, Milian Wolff escreveu:
> > > > On Thursday, August 4, 2016 10:22:25 AM CEST Arnaldo Carvalho de Melo
> > 
> > wrote:
> > > > > Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> > > > > > I hope this helps others. I finally have a working up2date perf on
> > > > > > my
> > > > > > aarch64 platform and it seems to work form my simple 5min tests so
> > > > > > far.
> > > > > 
> > > > > Ok, that should help people, but it is way convoluted :-\
> > > > > 
> > > > > How did you obtained your cross compiler environment? Some ready
> > > > > made
> > > > > tarball or set of distro packages? I have an ever growing set of
> > > > > perf
> > > > 
> > > > > build cointainers that includes a few cross compilers:
> > > > The environment was provided to us as a tarball from a customer of
> > > > ours,
> > > > who probably got that from another subcontractor.
> > > > 
> > > > <snip>
> > > > 
> > > >     export INSTALLDIR=/usr/${TARGET} && \
> > > > 
> > > > ^-- is that path potentially special cased in the build file? I mean
> > > > you
> > > > don't
> > > 
> > > Huh? Not that I am aware, no, I just looked at where the existing cross
> > > build packages were located, so that I used the same place for the cross
> 
> > > built versions of libelf and zlib:
>  <snip>
> 
> > > etc. So I assumed the best place to install the zlib and libelf devel
> > > files
> > > was with that path prefix.
> > 
> > Right, I think my point above was not clear: Since you essentially put
> > your
> > custom libelf into the implicit sysroot and also don't specify any prefix
> > to install to, it seems to work out of the box. Is this the common way
> > people build perf?
> 
> I have no idea besides what is documented for android in
> tools/perf/Documentation/, and that uses a --sysroot
> 
> > From my experience working on e.g. KDE, one often has the sysroot
> > (e.g. /usr), and then a bunch of custom stuff in a prefix somewhere in
> > $HOME. Doing that with perf seems to be "hard", as it's not enough to do
> > 
> >     make prefix=$HOME/path/to/foo
> > 
> > but instead one also needs to pass `-I.../include` and `-L.../lib` to
> > EXTRA_CFLAGS & LDFLAGS. I'd be willing to supply a patch to simplify this
> > process, if you think that is acceptable.
> > 
> > > See it running:
> > <snip>
> > 
> > > See? The features it is finding are just the ones related to having
> > > glibc,
> > > zlib and libelf devel packages that can be used in a cross build.
> > 
> > OK, good to know. Then this clearly is something else special to my setup,
> > similar to my initial problems with `--sysroot` being defined in `CC`
> > rather than `EXTRA_CFLAGS`. I'll try to dig into that eventually.
> > 
> > > > set the sysroot anywhere, nor do you seem to pass special include
> > > > paths to
> > > > perf. This of course works fine in a docker environment, but for
> > > > "normal"
> > > > development machines, where you compile and install stuff somewhere in
> > > > $HOME, this won't work at all.
> > > 
> > > Hey, a "docker environment" should be no different than a "normal"
> > > development machine, it should work just the same, its just the former
> > > will
> > > run inside a container, but the packages are the same I would install in
> > > my
> > > workstation if I wanted to pollute it with a cross compiler environment.
> > > Since I want to install tons of cross compiler environments, I better
> > > use
> > > some sort of container, docker being the most popular, I picked it.
> > 
> > My point here is exactly the pollution that happens in my non-containered
> > environment. There, I have tons of dev packages installed in e.g. /usr,
> > which may potentially get picked up, as well as the "actual" stuff that
> > should be used from the sysroot. But, again, at this point this is just
> > speculation.
> Sure, this is a valid concern and one that should grand creating a few
> more containers, taking advantage of its layers stuff to reduce the
> space needed, i.e. share the base stuff I have and then have another set
> with the native devel packages, to test that there is no pollution and
> the results are the expected ones in a cross compile env.
> 
> > If you have the time, could you try to install some more x86 dev packages
> > in your docker environments? E.g. when you install libunwind(-x86-64) -
> > does it
> I'll try what I described above, which is in line with your suggestion.
> 
> > then get picked up by your arm cross compile, or does it work as it
> > should?
> > That data point would help me figure out what could go wrong.
> 
> Will try tomorrow, if time allows, and will do it in the container
> fashion, i.e. it should be a few more containers, testing this
> possibility.

Update: It seems to me that the above mess-up was due to some left-over build 
artifact. I just tried to reproduce this with an up2date git checkout after 
doing a hearty `git clean -xfd` in my linux tree. The issue is gone. I thought 
to have done that before, but apparently that is not the case...

Sorry for the noise. I hope it may help someone out there who might run into 
that issue again in the future. I'll remember to use `git clean -xfd` before I 
report any other build related issues.

Cheers

-- 
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]