All of lore.kernel.org
 help / color / mirror / Atom feed
* libcansocket: Weird issue with pkgsplit
@ 2021-03-25  8:06 Tuomas Huuki
  2021-03-25 18:29 ` [yocto] " Khem Raj
  0 siblings, 1 reply; 4+ messages in thread
From: Tuomas Huuki @ 2021-03-25  8:06 UTC (permalink / raw)
  To: yocto

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

Hello all,
I have an interesting situation with libcansocket and bitbake that I cannot wrap my head around. For some reason, the packages are being split up somewhat strangely and I cannot figure out why.
First of all, the recipe used is:
https://github.com/openembedded/meta-openembedded/blob/9a0de2779b9b31f134ffe19388b5b9b37bb6450e/meta-oe/recipes-extended/socketcan/libsocketcan_0.0.11.bb
So no strange things there.

Additionally, looking at the built items:
../build/tmp/work/aarch64-poky-linux/libsocketcan/0.0.11-r0/image/usr/lib$ ls -lah libsocketcan*
lrwxrwxrwx 1 tuomas tuomas  21 maali 18 10:38 libsocketcan.so -> libsocketcan.so.2.3.0
lrwxrwxrwx 1 tuomas tuomas  21 maali 18 10:38 libsocketcan.so.2 -> libsocketcan.so.2.3.0
-rwxr-xr-x 1 tuomas tuomas 58K maali 18 10:38 libsocketcan.so.2.3.0

All looks good at this point. Now, when I deploy the image, the first link is missing.
When I look at pkgdata I can see that the link ends up in libsocketcan-dev:

$ oe-pkgdata-util list-pkg-files libsocketcan
libsocketcan:
    /usr/lib/libsocketcan.so.2
    /usr/lib/libsocketcan.so.2.3.0
$ oe-pkgdata-util list-pkg-files libsocketcan-dev
libsocketcan-dev:
    /usr/include/can_netlink.h
    /usr/include/libsocketcan.h
    /usr/lib/libsocketcan.so
    /usr/lib/pkgconfig/libsocketcan.pc

I have been through the logs and cannot figure out why.
I tried adding:

FILES_${PN} += " ${libdir} /*.so"
But no luck.

Looking at pkgdata/runtime/libsocketcan I notice:
FILES_libsocketcan: /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* /usr/lib/*.so
FILES_INFO: {"/usr/lib/libsocketcan.so.2": 21, "/usr/lib/libsocketcan.so.2.3.0": 14080}
pkg_postinst_libsocketcan:
#!/bin/sh\nset -e\nif [ x"$D" = "x" ]; then\n\tif [ -x /sbin/ldconfig 
]; then /sbin/ldconfig ; fi\nfi\n
FILERPROVIDESFLIST_libsocketcan: /usr/lib/libsocketcan.so.2.3.0
FILERPROVIDES_/usr/lib/libsocketcan.so.2.3.0_libsocketcan:  libsocketcan.so.2()(64bit)
FILERDEPENDSFLIST_libsocketcan: /usr/lib/libsocketcan.so.2.3.0
FILERDEPENDS_/usr/lib/libsocketcan.so.2.3.0_libsocketcan:
 ld-linux-aarch64.so.1(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.17)(64bit) 
libc.so.6()(64bit) ld-linux-aarch64.so.1()(64bit) rtld(GNU_HASH)
PKGSIZE_libsocketcan: 14101 But again this is missing the .so for some reason.

Additionally, I noticed that for some reason the package is renamed to libsocketcan2 (log.do_package).
Why? Could this be part of the issue?
> NOTE: debian: renaming libsocketcan to libsocketcan2

How does pkgconfig decide how to split packages. Can anyone point me to proper documentation?

Thanks!
Tuomas Huuki
Crosscontrol Oy

[-- Attachment #2: Type: text/html, Size: 3875 bytes --]

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

* Re: [yocto] libcansocket: Weird issue with pkgsplit
  2021-03-25  8:06 libcansocket: Weird issue with pkgsplit Tuomas Huuki
@ 2021-03-25 18:29 ` Khem Raj
  2021-03-26  6:07   ` Tuomas Huuki
  0 siblings, 1 reply; 4+ messages in thread
From: Khem Raj @ 2021-03-25 18:29 UTC (permalink / raw)
  To: Tuomas Huuki, yocto



On 3/25/21 1:06 AM, Tuomas Huuki wrote:
> Hello all,
> I have an interesting situation with libcansocket and bitbake that I 
> cannot wrap my head around. For some reason, the packages are being 
> split up somewhat strangely and I cannot figure out why.
> First of all, the recipe used is:
> https://github.com/openembedded/meta-openembedded/blob/9a0de2779b9b31f134ffe19388b5b9b37bb6450e/meta-oe/recipes-extended/socketcan/libsocketcan_0.0.11.bb 
> <https://github.com/openembedded/meta-openembedded/blob/9a0de2779b9b31f134ffe19388b5b9b37bb6450e/meta-oe/recipes-extended/socketcan/libsocketcan_0.0.11.bb>
> So no strange things there.
> 
> Additionally, looking at the built items:
> 
> ../build/tmp/work/aarch64-poky-linux/libsocketcan/0.0.11-r0/image/usr/lib$ ls -lah libsocketcan*
> lrwxrwxrwx 1 tuomas tuomas  21 maali 18 10:38 libsocketcan.so -> libsocketcan.so.2.3.0
> lrwxrwxrwx 1 tuomas tuomas  21 maali 18 10:38 libsocketcan.so.2 -> libsocketcan.so.2.3.0
> -rwxr-xr-x 1 tuomas tuomas 58K maali 18 10:38 libsocketcan.so.2.3.0
> 
> All looks good at this point. Now, when I deploy the image, the first 
> link is missing.
> When I look at pkgdata I can see that the link ends up in libsocketcan-dev:
> 
> $ oe-pkgdata-util list-pkg-files libsocketcan
> libsocketcan:
>      /usr/lib/libsocketcan.so.2
>      /usr/lib/libsocketcan.so.2.3.0
> $ oe-pkgdata-util list-pkg-files libsocketcan-dev
> libsocketcan-dev:
>      /usr/include/can_netlink.h
>      /usr/include/libsocketcan.h
>      /usr/lib/libsocketcan.so
>      /usr/lib/pkgconfig/libsocketcan.pc
> 


Its following usual soname naming conventions [1] for versioned shared 
libs where .so is a symlink which is used when something is linking to 
it during build time. thats why its in -dev package, if you want to use 
it at runtime then linker
will add proper versioned .so into DT_NEEDED sections of dependent 
package which will be libsocketcan.so.2 in this case. So if your program 
is trying to dlopen it then I would suggest to use libsocketcan.so.2 and 
if its trying to link to it during build time then it should add right 
entry into DT_NEEDED sections.

I am also wondering why would you want to move .so to main package.

[1] https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html


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

* [yocto] libcansocket: Weird issue with pkgsplit
  2021-03-25 18:29 ` [yocto] " Khem Raj
@ 2021-03-26  6:07   ` Tuomas Huuki
  2021-03-26  6:40     ` Khem Raj
  0 siblings, 1 reply; 4+ messages in thread
From: Tuomas Huuki @ 2021-03-26  6:07 UTC (permalink / raw)
  To: Khem Raj, yocto

Lähettäjä: Khem Raj <raj.khem@gmail.com> 
Lähetetty: torstai 25. maaliskuuta 2021 20.29
Vastaanottaja: Huuki, Tuomas <tuomas.huuki@crosscontrol.com>; yocto@lists.yoctoproject.org
Aihe: Re: [yocto] libcansocket: Weird issue with pkgsplit

[EXTERNAL SENDER] - If you believe this may be PHISHING, please click the "Report Phishing" button above.

On 3/25/21 1:06 AM, Tuomas Huuki wrote:
> Hello all,
> I have an interesting situation with libcansocket and bitbake that I 
> cannot wrap my head around. For some reason, the packages are being 
> split up somewhat strangely and I cannot figure out why.
> First of all, the recipe used is:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenembedded%2Fmeta-openembedded%2Fblob%2F9a0de2779b9b31f134f
> fe19388b5b9b37bb6450e%2Fmeta-oe%2Frecipes-extended%2Fsocketcan%2Flibso
> cketcan_0.0.11.bb&amp;data=04%7C01%7Ctuomas.huuki%40crosscontrol.com%7
> C8496799aa67e4cb3bac908d8efbbdd60%7C8b3fa9f59a3d4339a66aa9f7e39c9126%7
> C0%7C0%7C637522937456377594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hLiu
> fQtPTmCJvs1FfSemKVHnMmi5zBUKOHW%2BXgfMAyw%3D&amp;reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2Fopenembedded%2Fmeta-openembedded%2Fblob%2F9a0de2779b9b31f134
> ffe19388b5b9b37bb6450e%2Fmeta-oe%2Frecipes-extended%2Fsocketcan%2Flibs
> ocketcan_0.0.11.bb&amp;data=04%7C01%7Ctuomas.huuki%40crosscontrol.com%
> 7C8496799aa67e4cb3bac908d8efbbdd60%7C8b3fa9f59a3d4339a66aa9f7e39c9126%
> 7C0%7C0%7C637522937456387589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mp6
> vRRNyAG%2Bf2KnsAxxIWWMgjrmp%2BZSJWgU2rCVxGP4%3D&amp;reserved=0>
> So no strange things there.
>
> Additionally, looking at the built items:
>
> ../build/tmp/work/aarch64-poky-linux/libsocketcan/0.0.11-r0/image/usr/
> lib$ ls -lah libsocketcan* lrwxrwxrwx 1 tuomas tuomas  21 maali 18 
> 10:38 libsocketcan.so -> libsocketcan.so.2.3.0 lrwxrwxrwx 1 tuomas 
> tuomas  21 maali 18 10:38 libsocketcan.so.2 -> libsocketcan.so.2.3.0 
> -rwxr-xr-x 1 tuomas tuomas 58K maali 18 10:38 libsocketcan.so.2.3.0
>
> All looks good at this point. Now, when I deploy the image, the first 
> link is missing.
> When I look at pkgdata I can see that the link ends up in libsocketcan-dev:
>
> $ oe-pkgdata-util list-pkg-files libsocketcan
> libsocketcan:
>      /usr/lib/libsocketcan.so.2
>      /usr/lib/libsocketcan.so.2.3.0
> $ oe-pkgdata-util list-pkg-files libsocketcan-dev
> libsocketcan-dev:
>      /usr/include/can_netlink.h
>      /usr/include/libsocketcan.h
>      /usr/lib/libsocketcan.so
>      /usr/lib/pkgconfig/libsocketcan.pc
>

> Its following usual soname naming conventions [1] for versioned shared libs where .so is a symlink which is used when something is linking to it during build time. thats why its in -dev package, if you want to use it at runtime then linker will add proper versioned .so into DT_NEEDED sections of dependent package which will be libsocketcan.so.2 in this case. So if your program is trying to dlopen it then I would suggest to use libsocketcan.so.2 and if its trying to link to it during build time then it should add right entry into DT_NEEDED sections.
>
> I am also wondering why would you want to move .so to main package.

Thank you for the input! The request actually came from a client (a special case) and I started looking in to how to do this with Yocto/bitbake. It's still a little unclear to me how the package is split in to the different subpackages and how files end up in their locations. Any pointers on that?

Also, the other confusing thing is the naming, where the main library is renamed to libsocketcan2, but all the other packages are named libsocketcan.
-rw-r--r-- 3 tuomas tuomas 5,8K maali 25 10:19 libsocketcan2_0.0.11-r0.7_aarch64.ipk
-rw-r--r-- 3 tuomas tuomas  16K maali 25 10:19 libsocketcan-dbg_0.0.11-r0.7_aarch64.ipk
-rw-r--r-- 3 tuomas tuomas 3,1K maali 25 10:19 libsocketcan-dev_0.0.11-r0.7_aarch64.ipk
-rw-r--r-- 3 tuomas tuomas  13K maali 25 10:19 libsocketcan-doc_0.0.11-r0.7_aarch64.ipk
-rw-r--r-- 3 tuomas tuomas 8,9K maali 25 10:19 libsocketcan-src_0.0.11-r0.7_aarch64.ipk

But I guess that's just semantics.



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

* Re: [yocto] libcansocket: Weird issue with pkgsplit
  2021-03-26  6:07   ` Tuomas Huuki
@ 2021-03-26  6:40     ` Khem Raj
  0 siblings, 0 replies; 4+ messages in thread
From: Khem Raj @ 2021-03-26  6:40 UTC (permalink / raw)
  To: Huuki, Tuomas, yocto



On 3/25/21 11:07 PM, Huuki, Tuomas wrote:
> Lähettäjä: Khem Raj <raj.khem@gmail.com>
> Lähetetty: torstai 25. maaliskuuta 2021 20.29
> Vastaanottaja: Huuki, Tuomas <tuomas.huuki@crosscontrol.com>; yocto@lists.yoctoproject.org
> Aihe: Re: [yocto] libcansocket: Weird issue with pkgsplit
> 
> [EXTERNAL SENDER] - If you believe this may be PHISHING, please click the "Report Phishing" button above.
> 
> On 3/25/21 1:06 AM, Tuomas Huuki wrote:
>> Hello all,
>> I have an interesting situation with libcansocket and bitbake that I
>> cannot wrap my head around. For some reason, the packages are being
>> split up somewhat strangely and I cannot figure out why.
>> First of all, the recipe used is:
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> ub.com%2Fopenembedded%2Fmeta-openembedded%2Fblob%2F9a0de2779b9b31f134f
>> fe19388b5b9b37bb6450e%2Fmeta-oe%2Frecipes-extended%2Fsocketcan%2Flibso
>> cketcan_0.0.11.bb&amp;data=04%7C01%7Ctuomas.huuki%40crosscontrol.com%7
>> C8496799aa67e4cb3bac908d8efbbdd60%7C8b3fa9f59a3d4339a66aa9f7e39c9126%7
>> C0%7C0%7C637522937456377594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hLiu
>> fQtPTmCJvs1FfSemKVHnMmi5zBUKOHW%2BXgfMAyw%3D&amp;reserved=0
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> hub.com%2Fopenembedded%2Fmeta-openembedded%2Fblob%2F9a0de2779b9b31f134
>> ffe19388b5b9b37bb6450e%2Fmeta-oe%2Frecipes-extended%2Fsocketcan%2Flibs
>> ocketcan_0.0.11.bb&amp;data=04%7C01%7Ctuomas.huuki%40crosscontrol.com%
>> 7C8496799aa67e4cb3bac908d8efbbdd60%7C8b3fa9f59a3d4339a66aa9f7e39c9126%
>> 7C0%7C0%7C637522937456387589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mp6
>> vRRNyAG%2Bf2KnsAxxIWWMgjrmp%2BZSJWgU2rCVxGP4%3D&amp;reserved=0>
>> So no strange things there.
>>
>> Additionally, looking at the built items:
>>
>> ../build/tmp/work/aarch64-poky-linux/libsocketcan/0.0.11-r0/image/usr/
>> lib$ ls -lah libsocketcan* lrwxrwxrwx 1 tuomas tuomas  21 maali 18
>> 10:38 libsocketcan.so -> libsocketcan.so.2.3.0 lrwxrwxrwx 1 tuomas
>> tuomas  21 maali 18 10:38 libsocketcan.so.2 -> libsocketcan.so.2.3.0
>> -rwxr-xr-x 1 tuomas tuomas 58K maali 18 10:38 libsocketcan.so.2.3.0
>>
>> All looks good at this point. Now, when I deploy the image, the first
>> link is missing.
>> When I look at pkgdata I can see that the link ends up in libsocketcan-dev:
>>
>> $ oe-pkgdata-util list-pkg-files libsocketcan
>> libsocketcan:
>>       /usr/lib/libsocketcan.so.2
>>       /usr/lib/libsocketcan.so.2.3.0
>> $ oe-pkgdata-util list-pkg-files libsocketcan-dev
>> libsocketcan-dev:
>>       /usr/include/can_netlink.h
>>       /usr/include/libsocketcan.h
>>       /usr/lib/libsocketcan.so
>>       /usr/lib/pkgconfig/libsocketcan.pc
>>
> 
>> Its following usual soname naming conventions [1] for versioned shared libs where .so is a symlink which is used when something is linking to it during build time. thats why its in -dev package, if you want to use it at runtime then linker will add proper versioned .so into DT_NEEDED sections of dependent package which will be libsocketcan.so.2 in this case. So if your program is trying to dlopen it then I would suggest to use libsocketcan.so.2 and if its trying to link to it during build time then it should add right entry into DT_NEEDED sections.
>>
>> I am also wondering why would you want to move .so to main package.
> 
> Thank you for the input! The request actually came from a client (a special case) and I started looking in to how to do this with Yocto/bitbake. It's still a little unclear to me how the package is split in to the different subpackages and how files end up in their locations. Any pointers on that?

look at populate_packages() function in package.bbclass

> 
> Also, the other confusing thing is the naming, where the main library is renamed to libsocketcan2, but all the other packages are named libsocketcan.
> -rw-r--r-- 3 tuomas tuomas 5,8K maali 25 10:19 libsocketcan2_0.0.11-r0.7_aarch64.ipk
> -rw-r--r-- 3 tuomas tuomas  16K maali 25 10:19 libsocketcan-dbg_0.0.11-r0.7_aarch64.ipk
> -rw-r--r-- 3 tuomas tuomas 3,1K maali 25 10:19 libsocketcan-dev_0.0.11-r0.7_aarch64.ipk
> -rw-r--r-- 3 tuomas tuomas  13K maali 25 10:19 libsocketcan-doc_0.0.11-r0.7_aarch64.ipk
> -rw-r--r-- 3 tuomas tuomas 8,9K maali 25 10:19 libsocketcan-src_0.0.11-r0.7_aarch64.ipk
> 
> But I guess that's just semantics.
> 
> 

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

end of thread, other threads:[~2021-03-26  6:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-25  8:06 libcansocket: Weird issue with pkgsplit Tuomas Huuki
2021-03-25 18:29 ` [yocto] " Khem Raj
2021-03-26  6:07   ` Tuomas Huuki
2021-03-26  6:40     ` Khem Raj

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.