From: Christian Stewart <christian@paral.in>
To: buildroot@busybox.net
Subject: [Buildroot] systemd: build failure against pam on arm
Date: Fri, 29 Dec 2017 11:54:52 -0800 [thread overview]
Message-ID: <874lo9xqb7.fsf@paral.in> (raw)
In-Reply-To: <20171228180402.GR27558@waldemar-brodkorb.de>
Hi Waldemar,
Waldemar Brodkorb <wbx@openadk.org> writes:
>> Thank you again for taking the time to debug this, I've had this issue
>> early 2017 and have avoided upgrading Buildroot until we find a fix.
>
> Sorry I believe you entered the world of libtool hell.
>
> For the hardcore buildroot hackers, if you create a symlink in /lib
> pointing to libpam.so / libpam_misc.so you can reproduce the issue.
So there is a bug in libtool / Buildroot after all, when dealing with
/lib/libpam.so. I was previously able to bisect it down to a commit
upgrading the default Linux headers version, but I can't imagine this is
related.
> By the way, I couldn't reproduce the issue with OpenADK.
> Unfortunately I can't point to a specific patch.
> I always pass -Wl,-rpath-link -Wl,$(STAGING_DIR)/usr/lib in
> LDFLAGS and I always remove any .la files from staging directory.
My libtool knowledge is lacking... Is there a work-around I can apply to
force Buildroot to use these LDFLAGS? I could edit the autotools infra I
suppose, but this seems like a real hack.
> I do not patch the package provided ltmain.sh/libtool stuff like
> Buildroot, but I always use libtool 2.4.6 with a small patch
> like this when autoreconfing a package:
> +++ libtool-2.4.6/m4/libtool.m4
> - _LT_TAGVAR(hardcode_automatic, $1)=no
> + _LT_TAGVAR(hardcode_automatic, $1)=yes
If I try to change this in libtool in Buildroot:
checking whether the C compiler works... no
configure: error: in `/home/buildroot/skiff/workspaces/pi3/build/host-libtool-2.4.6':
configure: error: C compiler cannot create executables
I'm guessing I did it wrong? :)
> So sorry, I can't help you out of the hell.
Thanks for your help!
Best,
Christian
next prev parent reply other threads:[~2017-12-29 19:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 2:29 [Buildroot] systemd: build failure against pam on arm Christian Stewart
2017-06-01 18:36 ` Christian Stewart
2017-06-01 22:03 ` Peter Korsgaard
2017-06-01 23:35 ` Christian Stewart
2017-06-03 2:48 ` Christian Stewart
2017-06-03 10:54 ` Waldemar Brodkorb
2017-12-19 23:26 ` Christian Stewart
2017-12-20 0:31 ` Christian Stewart
2017-12-23 7:25 ` Christian Stewart
2017-12-23 10:06 ` Waldemar Brodkorb
2017-12-23 20:36 ` Christian Stewart
2017-12-24 10:38 ` Waldemar Brodkorb
2017-12-24 12:09 ` Waldemar Brodkorb
2017-12-25 1:35 ` Christian Stewart
2017-12-25 15:13 ` Waldemar Brodkorb
2017-12-26 21:50 ` Christian Stewart
2017-12-27 0:55 ` Christian Stewart
2017-12-27 3:05 ` Waldemar Brodkorb
2017-12-27 5:39 ` Christian Stewart
2017-12-27 8:05 ` Waldemar Brodkorb
[not found] ` <87o9mkdlf1.fsf@paral.in>
2017-12-28 18:04 ` Waldemar Brodkorb
2017-12-29 19:54 ` Christian Stewart [this message]
2018-02-14 2:55 ` Christian Stewart
2018-02-14 4:57 ` Waldemar Brodkorb
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=874lo9xqb7.fsf@paral.in \
--to=christian@paral.in \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox