Build System - libgd vs libgd-full Anomaly

I am experiencing a build system fault trying to build libgd-full

I had vnstat2, vnstati2, luci-app-vnstat, apcupsd-cgi installed/running on my last build that used libgd as a dependancy.

Recently I added bandwidthd-sqlite using opkg that turned into a bit of a fiasco. It needs libgd-full and I had to remove vnstat2, vnstati2, luci-app-vnstat, apcupsd-cgi, and libgd then add ligbd-full, re-install vnstat2, vnstati2, apcupsd-cgi, luci-app-vnstat and then finally add bandwidth-sqlite. An opkg workaround, but successful.

In any event, just having got a new gen12 core i7 12700H with 20 cores, it was time see how it's build performance faired. I added only bandwidthd-sqlite, sqlite3-cli to my nconfig, but I'm stumped on what is going on.

In my buildroot, I remove, vnstat2, vnstati2, luci-app-vnstat,apcupsd-cgi. This lets me de-select libgd and select libgd-full

I add bandwidthd-sqlite, and all looks good - empty libgd selection and libgd-full set with a splat. However when I try to add any of vnstat2, vnstati2, luci-app-vnstat, or apcupsd-cgi, they return libgd as a selected dependancy as well as libgd-full as a ` dependancy. Obviously, the build fails.

I can build it without vnstat2, vnstati2, luci-app-vnstat, apcupsd-cgi and then run opkg to install them after flashing the build and adding them back using opkg, but the idea is to custom build only what I use.

Any thoughts, insights, suggestions, 'try this' approaches are appreciated.

see PR

1 Like

Thanks. That does the trick. I didn't find any issues when I looked 3-4 weeks ago when I had the opkg runaround. Guess I should have looked again when it cropped up in my buildroot. :roll_eyes:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.