Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files
@ 2020-04-05 14:21 Thomas Petazzoni
  2020-04-05 21:21 ` Yann E. MORIN
  2020-04-08 14:32 ` Peter Korsgaard
  0 siblings, 2 replies; 3+ messages in thread
From: Thomas Petazzoni @ 2020-04-05 14:21 UTC (permalink / raw)
  To: buildroot

After the staging installation, we replace a number of paths in
libtool .la files so that those paths point to STAGING_DIR instead to
location in the build machine.

However, we replace only paths that start with /usr. And it turns out
that the linux-pam package is configured with --libdir=/lib (linux-pam
seems to always be installed in /lib rather than /usr/lib).

Due to this, libpam.la contains the following line:

  libdir='/lib'

When building a configuration that has:

 - BR2_ROOTFS_MERGED_USR=y
 - BR2_PACKAGE_LINUX_PAM=y
 - BR2_PACKAGE_POLKIT=y

on a system that has its system-wide PAM library installed in /lib,
the build fails with:

/lib/libpam.so: file not recognized: File format not recognized

For some reason, libtool searches only in STAGING_DIR/usr/lib, but
when BR2_ROOTFS_MERGED_USR=y, STAGING_DIR/lib points to
STAGING_DIR/usr/lib, so libtool finds libpam.la. And this libpam.la
contains a bogus libdir='/lib' path. libtool then goes on, finds
/lib/libpam.so, and links with it, causing the build failure.

By doing the proper replacement of libdir='/lib', we have a correct
libpam.la, and solve the build issue.

There is no autobuilder failure associated to this issue, as it
requires /lib/libpam.so to exist. This is the case on ArchLinux, on
which Xogium reported the issue, which can also be reproduced in an
ArchLinux container.

Reported-by: Xogium <contact@xogium.me>
Cc: Xogium <contact@xogium.me>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 package/pkg-generic.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 20b07a7fa9..7679c41556 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -329,6 +329,7 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
 				-e "s:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
 			-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
+			-e "s:\(['= ]\)/lib:\\1 at STAGING_DIR@/lib:g" \
 			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
 				-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
 			-e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
-- 
2.25.1

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [Buildroot] [PATCH] package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files
  2020-04-05 14:21 [Buildroot] [PATCH] package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files Thomas Petazzoni
@ 2020-04-05 21:21 ` Yann E. MORIN
  2020-04-08 14:32 ` Peter Korsgaard
  1 sibling, 0 replies; 3+ messages in thread
From: Yann E. MORIN @ 2020-04-05 21:21 UTC (permalink / raw)
  To: buildroot

Thomas, All,

On 2020-04-05 16:21 +0200, Thomas Petazzoni spake thusly:
> After the staging installation, we replace a number of paths in
> libtool .la files so that those paths point to STAGING_DIR instead to
> location in the build machine.
> 
> However, we replace only paths that start with /usr. And it turns out
> that the linux-pam package is configured with --libdir=/lib (linux-pam
> seems to always be installed in /lib rather than /usr/lib).
> 
> Due to this, libpam.la contains the following line:
> 
>   libdir='/lib'
> 
> When building a configuration that has:
> 
>  - BR2_ROOTFS_MERGED_USR=y
>  - BR2_PACKAGE_LINUX_PAM=y
>  - BR2_PACKAGE_POLKIT=y
> 
> on a system that has its system-wide PAM library installed in /lib,
> the build fails with:
> 
> /lib/libpam.so: file not recognized: File format not recognized
> 
> For some reason, libtool searches only in STAGING_DIR/usr/lib, but
> when BR2_ROOTFS_MERGED_USR=y, STAGING_DIR/lib points to
> STAGING_DIR/usr/lib, so libtool finds libpam.la. And this libpam.la
> contains a bogus libdir='/lib' path. libtool then goes on, finds
> /lib/libpam.so, and links with it, causing the build failure.
> 
> By doing the proper replacement of libdir='/lib', we have a correct
> libpam.la, and solve the build issue.
> 
> There is no autobuilder failure associated to this issue, as it
> requires /lib/libpam.so to exist. This is the case on ArchLinux, on
> which Xogium reported the issue, which can also be reproduced in an
> ArchLinux container.
> 
> Reported-by: Xogium <contact@xogium.me>
> Cc: Xogium <contact@xogium.me>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

I tested the build before/after the patch, with/without a /lib/libpam.so
(that I manually created on purpose). It was broken, it no longer is. ?

Applied to master, thanks.

Regards,
Yann E. MORIN.

> ---
>  package/pkg-generic.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index 20b07a7fa9..7679c41556 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -329,6 +329,7 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
>  			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
>  				-e "s:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
>  			-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
> +			-e "s:\(['= ]\)/lib:\\1 at STAGING_DIR@/lib:g" \
>  			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
>  				-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
>  			-e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
> -- 
> 2.25.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Buildroot] [PATCH] package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files
  2020-04-05 14:21 [Buildroot] [PATCH] package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files Thomas Petazzoni
  2020-04-05 21:21 ` Yann E. MORIN
@ 2020-04-08 14:32 ` Peter Korsgaard
  1 sibling, 0 replies; 3+ messages in thread
From: Peter Korsgaard @ 2020-04-08 14:32 UTC (permalink / raw)
  To: buildroot

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > After the staging installation, we replace a number of paths in
 > libtool .la files so that those paths point to STAGING_DIR instead to
 > location in the build machine.

 > However, we replace only paths that start with /usr. And it turns out
 > that the linux-pam package is configured with --libdir=/lib (linux-pam
 > seems to always be installed in /lib rather than /usr/lib).

 > Due to this, libpam.la contains the following line:

 >   libdir='/lib'

 > When building a configuration that has:

 >  - BR2_ROOTFS_MERGED_USR=y
 >  - BR2_PACKAGE_LINUX_PAM=y
 >  - BR2_PACKAGE_POLKIT=y

 > on a system that has its system-wide PAM library installed in /lib,
 > the build fails with:

 > /lib/libpam.so: file not recognized: File format not recognized

 > For some reason, libtool searches only in STAGING_DIR/usr/lib, but
 > when BR2_ROOTFS_MERGED_USR=y, STAGING_DIR/lib points to
 > STAGING_DIR/usr/lib, so libtool finds libpam.la. And this libpam.la
 > contains a bogus libdir='/lib' path. libtool then goes on, finds
 > /lib/libpam.so, and links with it, causing the build failure.

 > By doing the proper replacement of libdir='/lib', we have a correct
 > libpam.la, and solve the build issue.

 > There is no autobuilder failure associated to this issue, as it
 > requires /lib/libpam.so to exist. This is the case on ArchLinux, on
 > which Xogium reported the issue, which can also be reproduced in an
 > ArchLinux container.

 > Reported-by: Xogium <contact@xogium.me>
 > Cc: Xogium <contact@xogium.me>
 > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Committed to 2019.02.x, 2019.11.x and 2020.02.x, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-04-08 14:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-05 14:21 [Buildroot] [PATCH] package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files Thomas Petazzoni
2020-04-05 21:21 ` Yann E. MORIN
2020-04-08 14:32 ` Peter Korsgaard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox