Hi, i just realized that i always misunderstood or at least did not really think about how i bundle libs via DEPENDS:=+PACKAGE_libxy:libxy .
I had seen this shorthand and always assumed it means: if this optional lib is build + installed to the firmware anyway, than its also save to make my package depend on it. What i now noticed after actually checking the control file inside a ipk, is that all "optional" libs are added and handled like normal libs. That seems because the package-builders select all packages as module aka CONFIG_PACKAGE_xy=m and builds everything. So now all my supposed "optional" libs are actually required if you install via opkg.
So now i wonder if there is a way to add optional libs, only if they are actually build into the firmware image and not as module? The logic being, that if some other package actually needs the other lib, than we can also use/link against it. Yet as a module there is no reason to install all optional libs, just because we install via opkg.
Can you give me a example with a optional library for a package?
Probably I get you wrong, but I think there isn't something like a optional dependency.
How do you think should that work if some library is only optional?
Should the packaged program determine if the optional library is available and then expose some functionality that requires this optional library?
The second line are all libs that samba might make some use of, so reducing the final size or add some minor functionality to it, they are not actually a requirement to run the server.
Not really, what would make sense to me is that, if a lib is already build into the firmware image, because its actually a requirement by some other package, there is no harm in also linking/using it, since we cant really "uninstall" it from the image to save space. Yet if i check the samba4-server.ipk, all my supposed "optional" libs are now a install requirement.
Its my fault for sure and i need to wrap my head around this fact and see how to change the bundling logic.
The other example is my cifsd package, where i experiment with dynamic vs static build, based on if glib2 is present or not. DEPENDS:=+PACKAGE_glib2:glib2
So what makes sense to me is build the package shared, if some other package already needs glib2 and packages it into the image, while building it static otherwise to reduce size.
Even though they are not a requirement that the application works, I don't think this will work at runtime.
The Configure script, CMake or similar determines before the compilation starts what libraries are available and can be used.
Accordingly, features are not available or implemented differently in the later application.
For example, if libpthread is not available, multi threading is handled with fork()/exec().
At least that's my understanding.
I can't follow your reasoning.
If i understand you right, you want to add the dependency to glib2 only if PACKAGE_glib2 isn´t selected, right?
According to https://openwrt.org/docs/guide-developer/dependencies, it should look like: DEPENDS:=+!PACKAGE_glib2:glib2
Still, I don't understand what this is supposed to do.
I think only DEPENDS:=+glib2 should have the same resulting effect.
With this approach, you need to distinguish your package into two variants like default and static, but the same package once statically linked and once dynamically linked doesn´t make any sense.
You miss the point, i never talked about runtime checks.
The main confusion comes from how the build logic works in regards to a custom image build via sdk, where you want as much services as possible installed to the JFFS2 image itself vs how the build-bot's use the sdk via "build all" logic to generate the ipk's.
No, what i want to-do is trigger a shared build only if 'glib2' was already selected by some other package and do a static build otherwise.
Here is a example that demonstrates this, you build your own custom image and select cifsd, but no other package needs glib2, so i do a static build. Now later on you build a new image, but this time select Midnight Commander, which selects glib2. This time it makes sense to build cifsd via glib2 shared.
Yeah i also thought about this, but how would i handle luci? LUCI_DEPENDS:=+cifsd-server
I could only think of removing the dependency all-together, which is also a bit unusual? I could also make two luci variants ofc, but its also strange.
Ok after some thought, i think i just make it harder than it needs to-be. Instead of doing some "clever" build time detection/handling, i should just use the VARIANT logic and than accept the fact that my luci packages loose there service package dependency, so do not automatically install the service.
I think if this is ok for transmission, than it should work for my stuff as well.
PS: Regarding the samba4 lib's, i think the "real" solution is to just use whats "mostly" needed and patch those cases where samba4 just pulls in any optional lib it finds in stageing.