Compilation of x11-misc/compton-0.1_beta2 failed with: src/compton.h: In function 'lcfg_lookup_bool': src/compton.h:1109:7: error: too many arguments to function 'config_lookup_bool' if (config_lookup_bool(config, path, &ival)) ^ In file included from src/common.h:102:0, from src/compton.h:10, from src/compton.c:11: /usr/include/libconfig.h:205:26: note: declared here extern LIBCONFIG_API int config_lookup_bool(const config_t *config, ^ In file included from src/compton.c:11:0: src/compton.h: In function 'lcfg_lookup_int': src/compton.h:1127:14: error: too many arguments to function 'config_lookup_int' if ((ret = config_lookup_int(config, path, &lval))) ^ In file included from src/common.h:102:0, from src/compton.h:10, from src/compton.c:11: /usr/include/libconfig.h:201:27: note: declared here extern LIBCONFIG_API long config_lookup_int(const config_t *config, ^ src/compton.c: In function 'win_paint_win': src/compton.c:1641:5: warning: enumeration value 'NUM_BKEND' not handled in switch [-Wswitch] switch (ps->o.backend) { ^ src/compton.c: In function 'parse_config': src/compton.c:5119:7: error: too many arguments to function 'config_lookup_float' if (config_lookup_float(&cfg, "fade-in-step", &dval)) ^ In file included from src/common.h:102:0, from src/compton.h:10, from src/compton.c:11: /usr/include/libconfig.h:203:29: note: declared here and *many* others... Reason ====== The declarations in /usr/include/libconfig.h do not match the expectations in compton. This is because the libconfig.h is too old: equery belongs /usr/include/libconfig.h * Searching for /usr/include/libconfig.h ... dev-libs/libconfig-1.2 (/usr/include/libconfig.h) eix dev-libs/libconfig [U] dev-libs/libconfig Available versions: 1.5 {+cxx examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 1.2(12:38:13 pm 15/07/2008) So it tries to use a libconfig version from 2008! Solution ======= The ebuild should catch this - it does include libconfig in the dependencies list of compton, but there is no restriction on the version: dev-libs/libconfig This should be changed to something like >=dev-libs/libconfig-1.3 (assuming that one has checked that v. 1.3 of libconfig is OK - anyway, v. 1.2 is NOT). --- As an aside... --- An interesting question is why libconfig stayed in that old version for so long - and the answer is that no package depends on it (anymore?): qdepends -CQ dev-libs/libconfig (empty output) It is not in the world file: grep libconfig /var/lib/portage/world (empty output) so that an emerge --depclean --ask would have caught it and suggested it for deletion. But I have *never* run that... :-)
dev-libs/libconfig-1.5 went stable a year ago and stable 1.4.9 left the tree at that time. dev-libs/libconfig-1.2 left the tree five and a half years ago. You're supposed to update your system at some point and not rely on thousands of backward incompatibilities being recorded in the tree.
By 'update your system' I guess you mean 'do "emerge --depclean @world"'. Because I do update @system and @world at regular intervals that are definitively shorter than a year... My point is: since no package depended on libconfig and it was not in the world file, it was not updated, no matter how often I updated my system and world sets. You suggestion to 'update regularly' therefore amounts to 'do a depclean regularly' and, in such a case, I still fail to see the necessity of it. You are practically asking me to throw away parts of my installed packages, so that, at a later point, their newer versions will be pulled in when a package needs them. And why? Because the packager does not know, or does not care, which versions his package depends on... So, if you insist on updating, I have to ask you: how on earth was I supposed to update libconfig in this case? The only package that needs it on my system is compton - and it did not insist on a special version range. I installed compton a few days ago. For the past ten years, libconfig had been sitting there and nobody had even noticed. 'emerge @world' failed to pick it, since no package depended on it. Even if I had done a 'emerge --depclean --ask', I am quite sure I would have hesitated to say "yes" when asked if I was sure I wanted to eliminate libconfig...
(In reply to segmentation fault from comment #2) > By 'update your system' I guess you mean 'do "emerge --depclean @world"'. No, --depclean does not upgrade packages.
https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Updating_the_system
Nice of you to refer me to the standard docs...but, FYI, doing emerge --update --deep --with-bdeps=y @world did NOT catch that old libconfig in the past. And if you think about it, it is clear why (and I have said it already): no package depended on libconfig, up to the moment I installed compton - and compton was content with *any* version of it, so libconfig did not get upgraded even if it had to. FYI, this is a Gentoo that I installed 2006 and kept upgrading once in a few years (hundreds of packages each time, sometimes using ebuilds from portage snapshots to help me in-between), without *ever* doing a re-install. Somehow, libconfig managed to stay in that old version all the time. To only way to avoid this, would be to do a '--depclean', remove libconfig, then merge compton, which would then pull a fully new libconfig. That's why I said that what you are asking me ("update regularly") in this case is equivalent to "do a --depclean regularly and throw away everything that passes the --depclean test". I understand it is a rather minor point for a dispute, but for me it is a matter of principle: Even a emerge --update --deep --with-bdeps=y @world will NOT upgrade ALL packages, as we all know. It will upgrade only the packages in the world file, their immediate dependencies - and the dependencies of these dependencies. For a package like libconfig that somehow rests there in an old version, without needing anything and without being needed by anything, this 'standard' way will not upgrade it. Gentoo's logic is, for a package to be upgraded, either the user needs it, or a package needs it. If a user needs it, it should be in the world file. If a package needs it, its ebuild should say so. I can understand this logic, but only if *both* parts of it are followed. And the second part is important. If a package needs a higher version of some dependency, it should say so in its ebuild, otherwise it risks leaving a dependency that is neither in the world file, nor is a 'dependency of a dependency', in an old, unsuitable version. This breaks the logic of "we don't need to upgrade ALL packages, because 'world', its dependencies and their dependencies is *all* we really need for correct operation". I can also fully understand that a maintainer cannot know all possible combinations of versions that work for some particular package and its dependencies. But then, that's why we have bug reports like this - and people like me who like to 'dissect insects'... :-)
