* [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly
@ 2017-09-13 17:37 Andrey Smirnov
2017-09-13 18:55 ` Samuel Martin
0 siblings, 1 reply; 5+ messages in thread
From: Andrey Smirnov @ 2017-09-13 17:37 UTC (permalink / raw)
To: buildroot
Building host-lzo on 64-bit Fedora 26 ends up with library files
installed into $(HOST_DIR)/lib64 instead of $(HOST_DIR)/lib where
other packages (at least host-mtd) depending on it would look for it
(resulting in build failures). Fix that by specifying the directory to
be lib/ explicitly.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
I suspect this might not be the best solution for this problem, but it
is a good starting point to discuss what might be and that's why I
submitted this patch anyway.
Thanks,
Andrey Smirnov
package/lzo/lzo.mk | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/package/lzo/lzo.mk b/package/lzo/lzo.mk
index 27ca459acf..4eccbdc93a 100644
--- a/package/lzo/lzo.mk
+++ b/package/lzo/lzo.mk
@@ -23,5 +23,11 @@ else
LZO_CONF_OPTS += -DENABLE_STATIC=OFF
endif
+#
+# Make sure that libraries are installed in lib/ and not lib64/ so
+# that other packages can discover it
+#
+HOST_LZO_CONF_OPTS += -DCMAKE_INSTALL_LIBDIR=lib
+
$(eval $(cmake-package))
$(eval $(host-cmake-package))
--
2.13.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly
2017-09-13 17:37 [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly Andrey Smirnov
@ 2017-09-13 18:55 ` Samuel Martin
2017-09-13 20:43 ` Arnout Vandecappelle
0 siblings, 1 reply; 5+ messages in thread
From: Samuel Martin @ 2017-09-13 18:55 UTC (permalink / raw)
To: buildroot
Hi Andrey,
On Wed, Sep 13, 2017 at 7:37 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Building host-lzo on 64-bit Fedora 26 ends up with library files
> installed into $(HOST_DIR)/lib64 instead of $(HOST_DIR)/lib where
> other packages (at least host-mtd) depending on it would look for it
> (resulting in build failures). Fix that by specifying the directory to
> be lib/ explicitly.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
> ---
>
> I suspect this might not be the best solution for this problem, but it
> is a good starting point to discuss what might be and that's why I
> submitted this patch anyway.
Indeed the infra could certainly create the symlink $(HOST_DIR)/lib64
-> lib (or $(HOST_DIR)/lib32 -> lib).
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly
2017-09-13 18:55 ` Samuel Martin
@ 2017-09-13 20:43 ` Arnout Vandecappelle
2017-09-14 1:39 ` Andrey Smirnov
0 siblings, 1 reply; 5+ messages in thread
From: Arnout Vandecappelle @ 2017-09-13 20:43 UTC (permalink / raw)
To: buildroot
On 13-09-17 20:55, Samuel Martin wrote:
> Hi Andrey,
>
> On Wed, Sep 13, 2017 at 7:37 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> Building host-lzo on 64-bit Fedora 26 ends up with library files
>> installed into $(HOST_DIR)/lib64 instead of $(HOST_DIR)/lib where
>> other packages (at least host-mtd) depending on it would look for it
>> (resulting in build failures). Fix that by specifying the directory to
>> be lib/ explicitly.
It would be good to find out why this happens. I don't see anything in
CMakeLists.txt that could explain this.
Does this happen with the Buildroot-built host-cmake or only when you use the
system-installed one?
I expect this will happen with all host-cmake packages... Could you check?
Obviously, we need a more fundamental solution than this.
>>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>
> Acked-by: Samuel Martin <s.martin49@gmail.com>
Nacked by me, we need a more fundamental fix.
>
>> ---
>>
>> I suspect this might not be the best solution for this problem, but it
>> is a good starting point to discuss what might be and that's why I
>> submitted this patch anyway.
>
> Indeed the infra could certainly create the symlink $(HOST_DIR)/lib64
> -> lib (or $(HOST_DIR)/lib32 -> lib).
That could be a solution, but I don't like it very much... OTOH we do this for
staging/target already so why not for host.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly
2017-09-13 20:43 ` Arnout Vandecappelle
@ 2017-09-14 1:39 ` Andrey Smirnov
2017-09-18 20:17 ` Samuel Martin
0 siblings, 1 reply; 5+ messages in thread
From: Andrey Smirnov @ 2017-09-14 1:39 UTC (permalink / raw)
To: buildroot
On Wed, Sep 13, 2017 at 1:43 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
> On 13-09-17 20:55, Samuel Martin wrote:
>> Hi Andrey,
>>
>> On Wed, Sep 13, 2017 at 7:37 PM, Andrey Smirnov
>> <andrew.smirnov@gmail.com> wrote:
>>> Building host-lzo on 64-bit Fedora 26 ends up with library files
>>> installed into $(HOST_DIR)/lib64 instead of $(HOST_DIR)/lib where
>>> other packages (at least host-mtd) depending on it would look for it
>>> (resulting in build failures). Fix that by specifying the directory to
>>> be lib/ explicitly.
>
> It would be good to find out why this happens. I don't see anything in
> CMakeLists.txt that could explain this.
>
> Does this happen with the Buildroot-built host-cmake or only when you use the
> system-installed one?
>
> I expect this will happen with all host-cmake packages... Could you check?
>
> Obviously, we need a more fundamental solution than this.
>
Just finished digging more into this and it doesn't matter which CMake
is being used (I tried both). As far as I can tell the reason for this
behavior is the following code in CMake itself:
https://github.com/Kitware/CMake/blob/master/Modules/GNUInstallDirs.cmake#L201
I agree that this probably affects all "host-cmake" packages. I don't
have any data to back that up (meaning I didn't try to investigate
it), but I have a hunch that situation with "host-mtd" is exacerbated
by the fact that it uses AC_CHECK_LIB instead of relying on
PKG_CHECK_MODULES to find "lzo".
>>>
>>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>>
>> Acked-by: Samuel Martin <s.martin49@gmail.com>
>
> Nacked by me, we need a more fundamental fix.
>
>
>>
>>> ---
>>>
>>> I suspect this might not be the best solution for this problem, but it
>>> is a good starting point to discuss what might be and that's why I
>>> submitted this patch anyway.
>>
>> Indeed the infra could certainly create the symlink $(HOST_DIR)/lib64
>> -> lib (or $(HOST_DIR)/lib32 -> lib).
>
> That could be a solution, but I don't like it very much... OTOH we do this for
> staging/target already so why not for host.
>
I have no opinion on the matter, so I am happy to modify the patch to
do whatever you think is best.
Thanks,
Andrey Smirnov
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly
2017-09-14 1:39 ` Andrey Smirnov
@ 2017-09-18 20:17 ` Samuel Martin
0 siblings, 0 replies; 5+ messages in thread
From: Samuel Martin @ 2017-09-18 20:17 UTC (permalink / raw)
To: buildroot
Hi all,
On Thu, Sep 14, 2017 at 3:39 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> On Wed, Sep 13, 2017 at 1:43 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>>
>> On 13-09-17 20:55, Samuel Martin wrote:
>>> Hi Andrey,
>>>
>>> On Wed, Sep 13, 2017 at 7:37 PM, Andrey Smirnov
>>> <andrew.smirnov@gmail.com> wrote:
>>>> Building host-lzo on 64-bit Fedora 26 ends up with library files
>>>> installed into $(HOST_DIR)/lib64 instead of $(HOST_DIR)/lib where
>>>> other packages (at least host-mtd) depending on it would look for it
>>>> (resulting in build failures). Fix that by specifying the directory to
>>>> be lib/ explicitly.
>>
>> It would be good to find out why this happens. I don't see anything in
>> CMakeLists.txt that could explain this.
>>
>> Does this happen with the Buildroot-built host-cmake or only when you use the
>> system-installed one?
>>
>> I expect this will happen with all host-cmake packages... Could you check?
>>
>> Obviously, we need a more fundamental solution than this.
>>
>
> Just finished digging more into this and it doesn't matter which CMake
> is being used (I tried both). As far as I can tell the reason for this
> behavior is the following code in CMake itself:
>
> https://github.com/Kitware/CMake/blob/master/Modules/GNUInstallDirs.cmake#L201
>
> I agree that this probably affects all "host-cmake" packages. I don't
> have any data to back that up (meaning I didn't try to investigate
> it), but I have a hunch that situation with "host-mtd" is exacerbated
> by the fact that it uses AC_CHECK_LIB instead of relying on
> PKG_CHECK_MODULES to find "lzo".
I confirm this behavior is to be expected from any cmake package (both
host and target since CMake guesses it from the target-tuple), but
this does not trigger any trouble in the staging or target trees
because of the symlinks created by the skeleton-init-common package
So far, lzo is the only host-cmake-package installing libs that are
used by others host-packages.
All others host-cmake-packages only install programs under
$(HOST_DIR)/bin, without installing any libs; except for
host-mfgtools.
But host-mfgtools overrides its host install commands (installing it
in $(HOST_DIR)/lib), because no install rule is defined in its
CMakeLists.txt, so no install rule is generated in its Makefile.
BTW, the host-mfgtools program still has a valid RPATH pointing to
$(HOST_DIR)/lib, accordingly to $(HOST_LDFLAGS).
>
>>>>
>>>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>>>
>>> Acked-by: Samuel Martin <s.martin49@gmail.com>
>>
>> Nacked by me, we need a more fundamental fix.
>>
>>
>>>
>>>> ---
>>>>
>>>> I suspect this might not be the best solution for this problem, but it
>>>> is a good starting point to discuss what might be and that's why I
>>>> submitted this patch anyway.
>>>
>>> Indeed the infra could certainly create the symlink $(HOST_DIR)/lib64
>>> -> lib (or $(HOST_DIR)/lib32 -> lib).
>>
>> That could be a solution, but I don't like it very much... OTOH we do this for
>> staging/target already so why not for host.
>>
Another solution could be setting -DCMAKE_INSTALL_LIBDIR=lib as part
of the options of the host configure command in the infra.
But I'm really not sure about this, especially how it would play if a
host cmake package wants to set it (e.g. to install plugins)... it
sounds even more fragile than the symlink approach...
>
> I have no opinion on the matter, so I am happy to modify the patch to
> do whatever you think is best.
>
> Thanks,
> Andrey Smirnov
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-09-18 20:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-13 17:37 [Buildroot] [PATCH] package/lzo: Set CMAKE_INSTALL_LIBDIR for host variant explicitly Andrey Smirnov
2017-09-13 18:55 ` Samuel Martin
2017-09-13 20:43 ` Arnout Vandecappelle
2017-09-14 1:39 ` Andrey Smirnov
2017-09-18 20:17 ` Samuel Martin
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.