All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Seiderer <ps.report@gmx.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/4 RFC] xorg: fix installation paths (branch yem/xorg)
Date: Mon, 2 Nov 2015 18:19:02 +0100	[thread overview]
Message-ID: <20151102181902.33e379e9@gmx.net> (raw)
In-Reply-To: <56373D19.6080303@zacarias.com.ar>

Hello Gustavo,

On Mon, 2 Nov 2015 07:38:17 -0300, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:

> On 01/11/15 20:36, Peter Seiderer wrote:
> 
> >> The new pkconf bumped in d7f6d320 introduced a change in behaviour: all
> >> path variables returned by pkgconf are now prefixed with the sysroot
> >> directory.
> >>
> >
> > ...this commit breaks some other packages too, see [1] for libv4l example.
> >
> > This commit removed a patch named '0002-fix-double-sysroot.patch', I think
> > this patch should somehow be forward ported to the new pkconf packet...
> >
> > Regards,
> > Peter
> 
> Hi Peter.
> That's wrong, double-sysroot is natively removed by the newer versions 
> of pkgconf, if you have this:
> 
> ./usr/lib/pkgconfig/libxslt.pc:Libs: -L${libdir} -lxslt  -lxml2 
> -L/home/gustavoz/b/midx11/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib 
> -lz -lm -ldl -lm
> 
> And do this:
> 
> $ ./pkg-config --libs libxslt
> -L/home/gustavoz/b/midx11/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib 
> -lxslt  -lz -ldl -lm -lxml2
> 
> The output is as expected.
> 

But not correct for Qt, eg. for 'moc' while building lib4l, see eg. [1]:

Build statistics for 2015-11-01
===============================
[...]
    mips64el |                   libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/4ecf6d074a608a58d56e3567727028c0ca8dbe2b/
     powerpc |                   libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/d5198d50c2df194138aaf72a1b90bd8d2e272ea1/
[...]

Both fail with a wrong path for moc (not double sysroot but one time sysroot is one to much):

/bin/bash: /home/buildroot/buildroot-test/scripts/instance-1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/home/buildroot/buildroot-test/scripts/instance-1/output/host/usr/bin/moc: No such file or directory


/bin/sh: /home/buildroot/build/instance-0/output/host/usr/powerpc-buildroot-linux-uclibc/sysroot/home/buildroot/build/instance-0/output/host/usr/bin/moc: No such file or directory
Makefile:1154: recipe for target 'moc_qv4l2.cpp' failed


Or for my test build:

	$ ./host/usr/bin/pkg-config --variable=moc_location QtCore
/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/x86_64-buildroot-linux-gnu/sysroot/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/bin/moc

	$ cat cat ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/pkgconfig/QtCore.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/QtCore
qt_config=lex yacc warn_on uic resources qt warn_on release incremental link_prl cross_compile shared def_files_disabled no_mocdepend release qt_no_framework silent cross_compile release embedded largefile mmx 3dnow sse sse2 sse3 ssse3 sse4_1 sse4_2 avx exceptions_off dylib create_prl link_prl depend_includepath QTDIR_build qt_install_headers qt warn_on depend_includepath qmake_cache target_qt hide_symbols create_pc create_libtool explicitlib moc thread dll shared
moc_location=/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/bin/moc
uic_location=/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/bin/uic
rcc_location=/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/bin/rcc
lupdate_location=/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/bin/lupdate
lrelease_location=/home/seiderer/Work/build_i686_qt_v4l_utils/host/usr/bin/lrelease

Name: Qtcore
Description: Qtcore Library
Version: 4.8.7
Libs: -L${libdir} -lQtCore 
Libs.private: -L/usr/lib  -lpthread -lm -ldl -lrt  
Cflags: -DQT_SHARED -I/usr/include -I${includedir}

> The problem is two-fold as we discussed with Yann last night.
> On one side the pkg-config manpage says:
> 
>   PKG_CONFIG_SYSROOT_DIR
>    Modify  -I  and -L to use the directories located in target sys?
>    root.  this option is useful when cross-compiling packages  that
>    use  pkg-config  to  determine CFLAGS and LDFLAGS. -I and -L are
>    modified to point to the new system  root.  this  means  that  a
>    -I/usr/include/libfoo will become -I/var/target/usr/include/lib?
>    foo with a PKG_CONFIG_SYSROOT_DIR  equal  to  /var/target  (same
>    rule apply to -L)
> 
> So pkgconf is being "too happy" in applying the sysroot prefix to all 
> directories it finds in any variable.
> 
> On the other hand on the previous 0001-fix-variable.patch it did:
> 
> if ( !strcmp(req.variable, "includedir") ||
>          !strcmp(req.variable, "mapdir") ||
>          !strcmp(req.variable, "sdkdir") ||
>          !strcmp(req.variable, "libdir"))
>                printf("%s%s\n", sysroot_dir, req.buf);
>        else
>                printf("%s\n", req.buf);
> 
> So it was adding the sysroot prefix for mapdir & sdkdir as well, very 
> much out of specification (we'll call the manpage a spec), catering for 
> package abuse.
> 
> In the end our previous pkgconf was working out of spec, which may be 
> ok, but poses the question, how many of these variables should be 
> patched/prefixed as well? Because in the future other packages with 
> their $nonstandard variable may need this as well, and patching and 
> patching pkgconf for eternity doesn't sound so great.
> 
> First pkgconf should be patched to fix the out-of-spec functionality and 
> send that upstream, but variable exceptions won't roll.
> 
> For the second problem i think mangling the .pc files would be best for 
> the special variables, based on a per-package definition where you can 
> say which other variables should be prefixed.

Any suggestion how to fix the lib4vl case?

Regards,
Peter

> 
> Regards.

  reply	other threads:[~2015-11-02 17:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-01 23:00 [Buildroot] [PATCH 0/4 RFC] xorg: fix installation paths (branch yem/xorg) Yann E. MORIN
2015-11-01 23:00 ` [Buildroot] [PATCH 1/4 RFC] package/x11r7: introduce X11-global configure options Yann E. MORIN
2015-11-01 23:00 ` [Buildroot] [PATCH 2/4 RFC] package/x11r7/*: fixup all install paths Yann E. MORIN
2015-11-01 23:00 ` [Buildroot] [PATCH 3/4 RFC] core/pkg-generic: allow step hooks to fail a step Yann E. MORIN
2015-11-01 23:00 ` [Buildroot] [PATCH 4/4 RFC] core/pkg-generic: check proper package installation Yann E. MORIN
2015-11-01 23:36 ` [Buildroot] [PATCH 0/4 RFC] xorg: fix installation paths (branch yem/xorg) Peter Seiderer
2015-11-02 10:38   ` Gustavo Zacarias
2015-11-02 17:19     ` Peter Seiderer [this message]
2015-11-02 17:33       ` Yann E. MORIN
2015-11-02 18:04       ` Gustavo Zacarias

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=20151102181902.33e379e9@gmx.net \
    --to=ps.report@gmx.net \
    --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.