13576 2019-10-05 17:37:59 +0000 shared libs (.so) vs. static libs (.a) 2019-10-29 11:20:18 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other 2.7.2 All Multiple RESOLVED NOTABUG Undecided normal --- 1 pokylinux ross.burton richard.purdie --- --- Don't know oldest_to_newest 85223 0 pokylinux 2019-10-05 17:37:59 +0000 Please correct me if I'm wrong here, and/or please tell me what I am missing here * This is my understanding about .so packaging: * {PN}: main package, stripped (no symbols, no debug info) ── libhwtest-cmake-so-a │   └── usr │   └── lib │   ├── libhwtestcmake.so.0 -> libhwtestcmake.so.0.0.0 │   └── libhwtestcmake.so.0.0.0 {PN}-dbg: debug info (for debugging) ├── libhwtest-cmake-so-a-dbg │   └── usr │   └── lib │   └── .debug │   └── libhwtestcmake.so.0.0.0 {PN}-src: sources (for debugging) ── libhwtest-cmake-so-a-src │   └── usr │   └── src │   └── debug │   └── libhwtest-cmake-so-a │   └── 1.0-r0 │   ├── hwtest-cmake1.c │   └── hwtest-cmake2.c {PN}-src: for SDK ── libhwtest-cmake-so-a-dev │   └── usr │   ├── include │   │   └── hwtest-cmake.h │   └── lib │   └── libhwtestcmake.so -> libhwtestcmake.so.0 ----------------- so far so good and I guess I'm happy with this. * This is my understanding about .a (staticdev) packaging: * ├── libhw-cmake-a ├── libhw-cmake-a-dbg ├── libhw-cmake-a-dev <-- for the SDK │   └── usr │   └── include │   └── hw-cmake.h ├── libhw-cmake-a-doc ├── libhw-cmake-a-locale ├── libhw-cmake-a-src └── libhw-cmake-a-staticdev <-- for the SDK └── usr └── lib └── libhwcmake.a issue 1) {PN}-src: libhw-cmake-a-src seems to be empty by default, I thought it should contain the sources issue 2) {PN}-dbg, or {PN}-staticdev-dbg .debug └── libhw-cmake-a-staticdev.a libhw-cmake-a-dbg seems to be empty by default, I thought it should contain the debug info issue 3) {PN}-staticdev: libhw-cmake-a-staticdev.a seems to be with debug info and not stripped, I thought it should be stripped and without debug info Is it like this by design? {PN}-dev: ├── libhw-cmake-a-dev <-- for the SDK │ └── usr │ └── include │ └── hw-cmake.h we kind of agree ;) ---- ... and what should happen for a recipe which contains both .so and .a libs? ├── libhwtest-cmake-so-a │   └── usr │   └── lib │   ├── libhwtestcmake.so.0 -> libhwtestcmake.so.0.0.0 │   └── libhwtestcmake.so.0.0.0 ├── libhwtest-cmake-so-a-dbg │   └── usr │   └── lib │   └── .debug │   └── libhwtestcmake.so.0.0.0 ├── libhwtest-cmake-so-a-dev │   └── usr │   ├── include │   │   └── hwtest-cmake.h │   └── lib │   └── libhwtestcmake.so -> libhwtestcmake.so.0 ├── libhwtest-cmake-so-a-doc ├── libhwtest-cmake-so-a-locale ├── libhwtest-cmake-so-a.shlibdeps ├── libhwtest-cmake-so-a-src │   └── usr │   └── src │   └── debug │   └── libhwtest-cmake-so-a │   └── 1.0-r0 │   ├── hwtest-cmake1.c │   └── hwtest-cmake2.c └── libhwtest-cmake-so-a-staticdev └── usr └── lib └── libhwtestcmake.a I saw: No debugsrc is collected for static libraries: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12558 which might solve one of the problems (didn't try yet). Do we need {PN}-staticdev-dbg ? 85224 1 pokylinux 2019-10-05 17:39:20 +0000 (In reply to comment #0) > Please correct me if I'm wrong here, and/or please tell me what I am missing > here > > * This is my understanding about .so packaging: * > > {PN}: main package, stripped (no symbols, no debug info) > > ── libhwtest-cmake-so-a > │   └── usr > │   └── lib > │   ├── libhwtestcmake.so.0 -> libhwtestcmake.so.0.0.0 > │   └── libhwtestcmake.so.0.0.0 > > {PN}-dbg: debug info (for debugging) > > ├── libhwtest-cmake-so-a-dbg > │   └── usr > │   └── lib > │   └── .debug > │   └── libhwtestcmake.so.0.0.0 > > {PN}-src: sources (for debugging) > > ── libhwtest-cmake-so-a-src > │   └── usr > │   └── src > │   └── debug > │   └── libhwtest-cmake-so-a > │   └── 1.0-r0 > │   ├── hwtest-cmake1.c > │   └── hwtest-cmake2.c > > {PN}-src: for SDK {PN}-dev: for SDK > > ── libhwtest-cmake-so-a-dev > │   └── usr > │   ├── include > │   │   └── hwtest-cmake.h > │   └── lib > │   └── libhwtestcmake.so -> libhwtestcmake.so.0 > > > ----------------- > > so far so good and I guess I'm happy with this. > > * This is my understanding about .a (staticdev) packaging: * > > ├── libhw-cmake-a > ├── libhw-cmake-a-dbg > ├── libhw-cmake-a-dev <-- for the SDK > │   └── usr > │   └── include > │   └── hw-cmake.h > ├── libhw-cmake-a-doc > ├── libhw-cmake-a-locale > ├── libhw-cmake-a-src > └── libhw-cmake-a-staticdev <-- for the SDK > └── usr > └── lib > └── libhwcmake.a > > > issue 1) > > {PN}-src: > libhw-cmake-a-src seems to be empty by default, I thought it should contain > the sources > > issue 2) > > {PN}-dbg, or {PN}-staticdev-dbg > .debug > └── libhw-cmake-a-staticdev.a > > libhw-cmake-a-dbg seems to be empty by default, I thought it should contain > the debug info > > issue 3) > > {PN}-staticdev: > libhw-cmake-a-staticdev.a > seems to be with debug info and not stripped, I thought it should be > stripped and without debug info > > Is it like this by design? > > {PN}-dev: > ├── libhw-cmake-a-dev <-- for the SDK > │ └── usr > │ └── include > │ └── hw-cmake.h > > we kind of agree ;) > > ---- > ... and what should happen for a recipe which contains both .so and .a libs? > > ├── libhwtest-cmake-so-a > │   └── usr > │   └── lib > │   ├── libhwtestcmake.so.0 -> libhwtestcmake.so.0.0.0 > │   └── libhwtestcmake.so.0.0.0 > ├── libhwtest-cmake-so-a-dbg > │   └── usr > │   └── lib > │   └── .debug > │   └── libhwtestcmake.so.0.0.0 > ├── libhwtest-cmake-so-a-dev > │   └── usr > │   ├── include > │   │   └── hwtest-cmake.h > │   └── lib > │   └── libhwtestcmake.so -> libhwtestcmake.so.0 > ├── libhwtest-cmake-so-a-doc > ├── libhwtest-cmake-so-a-locale > ├── libhwtest-cmake-so-a.shlibdeps > ├── libhwtest-cmake-so-a-src > │   └── usr > │   └── src > │   └── debug > │   └── libhwtest-cmake-so-a > │   └── 1.0-r0 > │   ├── hwtest-cmake1.c > │   └── hwtest-cmake2.c > └── libhwtest-cmake-so-a-staticdev > └── usr > └── lib > └── libhwtestcmake.a > > I saw: > > No debugsrc is collected for static libraries: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12558 > > which might solve one of the problems (didn't try yet). > > Do we need {PN}-staticdev-dbg ? 85294 2 richard.purdie 2019-10-10 14:40:18 +0000 I think the key piece of information missing here is that we only have one -src package, one -dev package and one -dbg package for any given recipe. The same sources are used by several different packages for example. This means static packages would not have their own dbg/src/dev variants. 85310 3 pokylinux 2019-10-10 18:37:28 +0000 Does this imply, that static libs will always include debug info by design? How can I get rid of it? 85466 4 ross.burton 2019-10-29 11:20:18 +0000 Looking at package.bbclass, the stripping code has explicit logic to find static libraries. #12558 indeed fixes the source package problem (2.5 onwards). The dbg package should always be generated and populated for packages containing static libraries. If you have further issues please file a new bug but be specific about what you're expecting with concrete examples.