Simple question I can't find an answer for.
What should I write into Makefile in DEPENDS:= section if I want the target having busybox's pgrep (for example)? I know how to depend on the specific packages and their first level programs, but not on the component of the (standard) package buried deeper than first level... Is it documented anywhere?
Thank you!
Have you looked at/tried approaches from existing Makefiles in packages: https://github.com/search?q=repo%3Aopenwrt%2Fpackages+%2B!BUSYBOX_CONFIG&type=code ?
Thanks. I think I have figured out how to turn on external component if busybox component is not enabled.
Now I can't find how to enable specific busybox component, for example hexdump... Busybox config flag is BUSYBOX_CONFIG_HEXDUMP, but how to make it =y in makefile?
Edit: one more "better" question - how to do it properly (and if it is possible)? I see there's default busybox config, and custom config. Consider situation when any of these configs do not have hexdump enabled, but my package needs it. I do not see external package containing busybox, thus the only option is to somehow turn it on in busybox.
Base System->Customize Busybox Options->Linux System Utilities
Select hexdump
You can't enable/ disable busybox features from other packages, even if possible, such a change would not be accepted to the archive for busybox.
2 Likes
Thanks, bad news. Then is there an automatic way to ensure there's hexdump in the system at the time of the image compilation? If there would be respective external package I would write
+!BUSYBOX_CONFIG_HEXDUMP:external_hexdump
but there's no alternative as far as I can see.
I think I would even be ok if make would fail if there is no hexdump configured in the system = the goal is to prevent the situation when everything seems to be ok, but in the most interesting moment it says something like "sh: no such file".
I do not quite understand the problem about hexdump here (I'm on my phone and might miss the obvious, but...), hexdump should be unconditionally enabled by default (and as it is widely used in firstboot- and initscripts, it can't be disabled either).
Hexdump is just an example (however as far as I have seen it is possible to disable hexdump in busybox manual config mode). The general question - if package depends on specific busybox component (which may appear to be disabled) how to properly indicate it in the makefile?
Take a look at freeswitch Makefile from telephony repo.
# Note: shadow deps are a bit strange; you need to select shadow-utils
# package first for shadow-su to be selected, even though the
# shadow-utils package later becomes a no-op.
define Package/freeswitch
$(call Package/freeswitch/Default)
TITLE:=Open source telephony platform, v$(PKG_VERSION)
MENU:=1
USERID:=freeswitch=372:freeswitch=372
DEPENDS:= \
$(ICONV_DEPENDS) \
+libstdcpp \
+!BUSYBOX_DEFAULT_SU:shadow-utils \
+!BUSYBOX_DEFAULT_SU:shadow-su \
Hope this helps.
I would love so, but seems not.
Searched through repository: ICONV_DEPENDS:=+BUILD_NLS:libiconv-full
Regarding
+!BUSYBOX_DEFAULT_SU:shadow-utils \
+!BUSYBOX_DEFAULT_SU:shadow-su \
this instructs make to turn shadow-utils' su on in the distribution if default busybox's su is not enabled. The problem with example of hexdump above is that such functionality is not (at least readily) available in any external package...
Maybe, but those are intentionally guarded by expert config symbols and will set TAINT_BUSYBOX - and more importantly, disabling hexdump would brick many devices (hexdump -C is used all over the place, for very basic- and important tasks).
1 Like
Thanks. I took hexdump as an example.
Ok, it seems we do not know it, or it is not possible to change state of internal busybox component.
In respect to hexdump, its state in default configuration is controlled by BUSYBOX_DEFAULT_HEXDUMP and is set in my distro to y. If someone will set bysybox into "tainted" mode s/he can change the setting for BUSYBOX_CONFIG_HEXDUMP (from the BUSYBOX_DEFAULT_HEXDUMP being y), and hexdump will not appear in the output image (whatever consequences it will have).
So the question -
how to check BUSYBOX_CONFIG_HEXDUMP to be y during the make and terminate make if it is not y?
DEPENDS:=BUSYBOX_DEFAULT_HEXDUMP
In case busybox is configured to not build hexdump your package won't show up in menuconfig, so it won't be built.
Tried this before - here's menuconfig output
make menuconfig
Collecting package info: done
WARNING: Makefile 'package/mypackage/Makefile' has a dependency on 'BUSYBOX_DEFAULT_HEXDUMP', which does not exist
and of course my package does not appear in the list, while hexdump is selected in the busybox configuration. Same error for BUSYBOX_CONFIG_HEXDUMP.
My bad, put an '@' before it
DEPENDS:=@BUSYBOX_DEFAULT_HEXDUMP
1 Like
That works!
So in conclusion - we still do not know if we can turn the busybox component on automatically in dependencies list for specific package, but we may make this specific package being hidden until busybox component is selected.
Now I see another issue... I copy the package into the host, run make menuconfig, do not see it there - and wonder how can I figure out in more or less readable form what is actually missing. I can of course go into makefile for the package and see things there - but is there a way to "unhide" package in menuconfig to check the make settigns?
I think we do know that we can't turn on busybox components from a package's list of dependencies, because the busybox components are set up to be configured via upper case config symbols (CONFIG_FOO). And according to the OpenWrt documentation we can only depend on a symbol ("@FOO") and select another package "bar" when a symbol is set ("+FOO:"). The documentation does not say that we can also select a symbol from a package dependency (that would be "+@FOO", which is not documented).
The main reason in my opinion is simple. busybox is a single binary that includes a multitude of different smaller programs (sed, grep etc.). They are just symbolic links on the file system, all pointing to busybox. That's how busybox knows what program you actually want it to execute. So there is no busybox plugin package that you can just install on the fly to install missing hexdump capability for example. You'd need to recompile busybox to change its feature set.
Or put in another way, if you have a package that depends on hexdump, what can opkg do in the case that the currently installed busybox doesn't support hexdump and then you ask it to install a package that depends on hexdump? It can do exactly nothing do add the missing hexdump functionality to busybox.
If on the other hand there existed a package that included another hexdump, then you could use DEPENDS:=+BUSYBOX_DEFAULT_HEXDUMP:hexdump to depend on this extra package if the system you compile for does not have the hexdump capability present in busybox.
And in case you're wondering, busybox is not a package that anybody in a sound state of mind would try to upgrade on a live OpenWrt device.
What you wrote in your second paragraph I cannot understand. With "copy package to host" you mean copying the package to an OpenWrt router I take it? If yes, why would you try to run "make menuconfig" on the router? You just install the package and then you use it. There must be some kind of misunderstanding here.
4 Likes
Host is the machine where compilation is performed (router is the target machine). I meant copy source code into the compilation bench, and then trying to configure the compilation of OS image using make menuconfig. If package you just copied into there is hidden, you can't (?) look into its dependencies in the menuconfig because there's no package to select. Menuconfig is convenient as it shows which required packages or components are included (y) and which are not (n) and thus you can quickly see what package/component to look for to include for this new package to get activated in the menu.
This is not a big problem - it just would be very convenient.