Skip to contentSkip to conversation

host-lzo: default liblzo2.a install to host/lib

PATCH New Matt Weber 3 participants 6 messages Oct 3, 2017

lore
Share & tools
lore

Matt Weber

author
#0 lore raw

PATCH 1/1 host-lzo: default liblzo2.a install to host/lib

Discovered the issue on a RHEL7.4 machine where the cmake build dynamically selected HOST_DIR/lib64 as the installation path for the library.

Fixes failures like the following:
host-mtd
http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/
host-squashfs
http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/

Signed-off-by Matthew Weber <[email protected]>
---
 package/lzo/lzo.mk | 3 +++
 1 file changed, 3 insertions(+)
package/lzo/lzo.mk +3 -0
index 27ca459..0cafba2 100644
@@ -11,6 +11,9 @@ LZO_LICENSE_FILES = COPYING
 LZO_INSTALL_STAGING = YES
 LZO_SUPPORTS_IN_SOURCE_BUILD = NO
 
+# Prevent dynamically using lib64 as install libdir
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib
+
 ifeq ($(BR2_SHARED_LIBS)$(BR2_SHARED_STATIC_LIBS),y)
 LZO_CONF_OPTS += -DENABLE_SHARED=ON
 else
Signature · 1 line
1.8.3.1
#1 lore raw

PATCH 1/1 host-lzo: default liblzo2.a install to host/lib

Matthew, All,

On 2017-10-03 08:49 -0500, Matt Weber spake thusly:

Quoted 20 lines

Discovered the issue on a RHEL7.4 machine where the cmake build dynamically selected HOST_DIR/lib64 as the installation path for the library.

Fixes failures like the following:
host-mtd
http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/
host-squashfs
http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/

Signed-off-by Matthew Weber <[email protected]>
---
 package/lzo/lzo.mk | 3 +++
 1 file changed, 3 insertions(+)
package/lzo/lzo.mk +0 -0
index 27ca459..0cafba2 100644

package/lzo/lzo.mk LZO_LICENSE_FILES = COPYING · line 15

Quoted 5 lines
package/lzo/lzo.mk +2 -0
@@ -11,6 +11,9 @@ LZO_LICENSE_FILES = COPYING
 LZO_INSTALL_STAGING = YES
 LZO_SUPPORTS_IN_SOURCE_BUILD = NO
 
+# Prevent dynamically using lib64 as install libdir
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib

So, probably other packages would have the same issue, then? And indeed, we've just had Jan on IRC reporting the same issue with a new package he's adding.

So I suggest that we simply symlink lib64 -> lib like we do for the target, and be done with it.

Thoughts?

Regards,
Yann E. MORIN.

Quoted 10 lines
package/lzo/lzo.mk +0 -0
 ifeq ($(BR2_SHARED_LIBS)$(BR2_SHARED_STATIC_LIBS),y)
 LZO_CONF_OPTS += -DENABLE_SHARED=ON
 else
Signature · 6 lines
1.8.3.1

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#2 lore raw

PATCH 1/1 host-lzo: default liblzo2.a install to host/lib

Yann,

Quoted 33 lines · Yann E. MORIN

Matthew, All,

On 2017-10-03 08:49 -0500, Matt Weber spake thusly:

Quoted 20 lines

Discovered the issue on a RHEL7.4 machine where the cmake build dynamically selected HOST_DIR/lib64 as the installation path for the library.

Fixes failures like the following:
host-mtd
http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/
host-squashfs
http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/

Signed-off-by Matthew Weber <[email protected]>
---
 package/lzo/lzo.mk | 3 +++
 1 file changed, 3 insertions(+)
package/lzo/lzo.mk +0 -0
index 27ca459..0cafba2 100644

package/lzo/lzo.mk LZO_LICENSE_FILES = COPYING · line 15

Quoted 5 lines
package/lzo/lzo.mk +2 -0
@@ -11,6 +11,9 @@ LZO_LICENSE_FILES = COPYING
 LZO_INSTALL_STAGING = YES
 LZO_SUPPORTS_IN_SOURCE_BUILD = NO
 
+# Prevent dynamically using lib64 as install libdir
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib

So, probably other packages would have the same issue, then? And indeed, we've just had Jan on IRC reporting the same issue with a new package he's adding.

Quoted 4 lines

So I suggest that we simply symlink lib64 -> lib like we do for the target, and be done with it.

Thoughts?

Sounds reasonable, so something we'd add in the Makefile by the following? # Compatibility symlink in case a post-build script still uses $(HOST_DIR)/usr $(HOST_DIR)/usr: $(HOST_DIR)

        @ln -snf . $@

Matt

author
#3 lore raw

PATCH 1/1 host-lzo: default liblzo2.a install to host/lib

Yann,

Quoted 39 lines · Matthew Weber

Yann,

Quoted 36 lines · Yann E. MORIN

Matthew, All,

On 2017-10-03 08:49 -0500, Matt Weber spake thusly:

Quoted 20 lines

Discovered the issue on a RHEL7.4 machine where the cmake build dynamically selected HOST_DIR/lib64 as the installation path for the library.

Fixes failures like the following:
host-mtd
http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/
host-squashfs
http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/

Signed-off-by Matthew Weber <[email protected]>
---
 package/lzo/lzo.mk | 3 +++
 1 file changed, 3 insertions(+)
package/lzo/lzo.mk +0 -0
index 27ca459..0cafba2 100644

package/lzo/lzo.mk LZO_LICENSE_FILES = COPYING · line 15

Quoted 5 lines
package/lzo/lzo.mk +2 -0
@@ -11,6 +11,9 @@ LZO_LICENSE_FILES = COPYING
 LZO_INSTALL_STAGING = YES
 LZO_SUPPORTS_IN_SOURCE_BUILD = NO
 
+# Prevent dynamically using lib64 as install libdir
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib

So, probably other packages would have the same issue, then? And indeed, we've just had Jan on IRC reporting the same issue with a new package he's adding.

So I suggest that we simply symlink lib64 -> lib like we do for the target, and be done with it.

Quoted 7 lines
Quoted 1 line

Thoughts?

Sounds reasonable, so something we'd add in the Makefile by the following? # Compatibility symlink in case a post-build script still uses $(HOST_DIR)/usr $(HOST_DIR)/usr: $(HOST_DIR)

        @ln -snf . $@

Something like this (testing it now)

# Make a symlink lib32->lib or lib64->lib as appropriate. # MIPS64/n32 requires lib32 even though it's a 64-bit arch. ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) $(HOST_DIR)/lib64: $(HOST_DIR)

        @ln -snf lib $@
else
$(HOST_DIR)/lib32: $(HOST_DIR)
        @ln -snf lib $@

endif

author
#4 lore raw

PATCH 1/1 host-lzo: default liblzo2.a install to host/lib

Yann,

Quoted 44 lines · Matthew Weber

Yann,

Quoted 40 lines · Matthew Weber

Yann,

Quoted 37 lines · Yann E. MORIN

Matthew, All,

On 2017-10-03 08:49 -0500, Matt Weber spake thusly:

Quoted 20 lines

Discovered the issue on a RHEL7.4 machine where the cmake build dynamically selected HOST_DIR/lib64 as the installation path for the library.

Fixes failures like the following:
host-mtd
http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/
host-squashfs
http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/

Signed-off-by Matthew Weber <[email protected]>
---
 package/lzo/lzo.mk | 3 +++
 1 file changed, 3 insertions(+)
package/lzo/lzo.mk +0 -0
index 27ca459..0cafba2 100644

package/lzo/lzo.mk LZO_LICENSE_FILES = COPYING · line 15

Quoted 5 lines
package/lzo/lzo.mk +2 -0
@@ -11,6 +11,9 @@ LZO_LICENSE_FILES = COPYING
 LZO_INSTALL_STAGING = YES
 LZO_SUPPORTS_IN_SOURCE_BUILD = NO
 
+# Prevent dynamically using lib64 as install libdir
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib

So, probably other packages would have the same issue, then? And indeed, we've just had Jan on IRC reporting the same issue with a new package he's adding.

So I suggest that we simply symlink lib64 -> lib like we do for the target, and be done with it.

Thoughts?

Proposed patch to supersede this lzo patch using the symlink approach. Tested with a 32bit and 64bit archs.
https://patchwork.ozlabs.org/patch/820978/

#5 lore raw

PATCH 1/1 host-lzo: default liblzo2.a install to host/lib

In reply to Yann E. MORIN

Hello,

Quoted 11 lines · Yann E. MORIN

package/lzo/lzo.mk LZO_LICENSE_FILES = COPYING · line 15

Quoted 2 lines
package/lzo/lzo.mk +2 -0
+# Prevent dynamically using lib64 as install libdir
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib

So, probably other packages would have the same issue, then? And indeed, we've just had Jan on IRC reporting the same issue with a new package he's adding.

So I suggest that we simply symlink lib64 -> lib like we do for the target, and be done with it.

Thoughts?

Yes, I also think we need a more general solution that fixing each package one by one.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com