emerging gnome-games fails with: i686-pc-linux-gnu-gcc -O2 -march=pentium-m -fomit-frame-pointer -o sol sol.o slot.o dialog.o cscmi.o events.o press_data.o draw.o menu.o card.o statistics.o -pthread -Wl,-z -Wl,now -Wl,--export-dynamic ../libgames-support/.libs/libgames-support.a /usr/lib/libgnomeui-2.so -L/usr/lib /usr/lib/libjpeg.so /usr/lib/libbonoboui-2.so /usr/lib/libgnome-keyring.so /usr/lib/libgnomecanvas-2.so /usr/lib/libgnome-2.so /usr/lib/libesd.so /usr/lib/libaudiofile.so /usr/lib/libasound.so /usr/lib/libart_lgpl_2.so /usr/lib/libbonobo-2.so /usr/lib/libgnutls.so /usr/lib/libtasn1.so /usr/lib/libgcrypt.so /usr/lib/libgpg-error.so /usr/lib/libbonobo-activation.so /usr/lib/libORBitCosNaming-2.so /usr/lib/librsvg-2.so /usr/lib/libgnomevfs-2.so /usr/lib/libdbus-glib-1.so /usr/lib/libdbus-1.so -lnsl -lssl -lcrypto -lresolv -lutil /usr/lib/libgconf-2.so /usr/lib/libpopt.so /usr/lib/libORBit-2.so /usr/lib/libgthread-2.0.so -lpthread /usr/lib/libgsf-1.so -lbz2 /usr/lib/libcroco-0.6.so /usr/lib/libglade-2.0.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libexpat.so /usr/lib/libpango-1.0.so -lrt /usr/lib/libcairo.so /usr/lib/libfreetype.so /usr/lib/libfontconfig.so /usr/lib/libxml2.so /usr/lib/libglitz.so /usr/lib/libpng12.so -lz /usr/lib/libXrender.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so /usr/lib/libguile.so /usr/lib/libgmp.so -lcrypt -lm /usr/lib/libltdl.so -ldl dialog.o: In function `show_hint_dialog': dialog.c:(.text+0x500): undefined reference to `SCM_NFALSEP' dialog.c:(.text+0x51d): undefined reference to `scm_num2int' ... cscmi.c:(.text+0x6c): undefined reference to `scm_long2num' cscmi.o: In function `c2scm_deck': cscmi.c:(.text+0xaf): undefined reference to `SCM_BOOL' ... Reproducible: Always
Created attachment 108199 [details] emerge --info
You apparently need guile-1.8 with deprecated and discouraged USE flags for gnome-games to work with guile USE flag. Need to discuss the introduction of these USE flags further with the dev-scheme/guile maintainer.
Can someone give an example of how to specify Guile USE flags in /etc/portage/package.use to enable gnome-games to compile successfully?
Please disregard my last reply to this bug. I did of course figure it out immediately after committing it... :-(
*** Bug 166165 has been marked as a duplicate of this bug. ***
*** Bug 166174 has been marked as a duplicate of this bug. ***
app-office/gnotime also fails because of this. Scheme team/hkBst, please reconsider having the discouraged and deprecated USE flags or share your thoughts. Many packages need them and built_with_use on two different USE flags on multiple packages and them being for enabling stuff that is extensively used with programs designed for guile-1.{5.6?} gives pain and a very bad migration path over all package visibility states (unstable, stable) from the newer guile.
discouraged is already implied by deprecated (because of guile compilation failure otherwise), so you only need to check for deprecated use flag to get compatibility stuff.
*** Bug 168914 has been marked as a duplicate of this bug. ***
Question: How are we supposed to ensure stable packages work with ~guile? After all, stable guile doesn't have discourgaged or deprecated USE flags, so we can't test for them; I guess we're going to have to hard dep on 1.6.x, unless those flags can be removed and the compat code built in automatically.
yes, if packages won't work with guile-1.8 then you will have to harddep on 1.6. For testing use flags on guile-1.8 only you can use the following code: if has_version =guile-1.8*; then local flags="deprecated regex" built_with_use dev-scheme/guile ${flags} || die "guile must be built with \"${flags}\" use flags" fi possibly augmented with an eerror to mirror the die.
(In reply to comment #11) > yes, if packages won't work with guile-1.8 then you will have to harddep on 1.6. guile 1.6 and 1.8 are in the same SLOT - we can't harddep on 1.6 without causing major headaches to users with upgrade-downgrade cycles. I assume you have reconsidered having discouraged and deprecated USE flags for guile, and are going to keep them? The problem with them in my eyes is that it gives no real benefits and it gives problems like we are having here. A user shouldn't care about having or not having discouraged API included in a package or not. These USE flags are not something that add functionality - they are something that make you recompile guile after trying to install a popular package that simply has to still support guile-1.6 too, learn about local USE flags setting, and waste time from all that. The only benefit I have heard is that it helps developers not use discouraged or deprecated guile API when they are developing something. This is not the way in which I think this should be achieved sanely. Other libraries achieve this nicely by allowing the developer to define a preprocessor macro that says to not include function prototypes and forward declarations of deprecated symbols and it works really good - and doesn't involve breaking the ABI on a same SLOT upgrade with the default set of USE flags. Having USE flags for controlling deprecated stuff in a library kind of thing seems to be a precedent in this case. So, are these USE flags going to be kept, instead of just enabling them always without new USE flags?
There doesn't seem to be anything i can do about the slotting and I can't help that some packages still don't work with guile-1.8, after 1.8.0 came out on 12 feb 2006, even when deprecated features are enabled. Calling guile a library is not very enlightening. Guile is a programming language. If you want all the compatibility stuff than all you need is the deprecated use flag, but I think it is good that you can also disable deprecated stuff, which is why I think it is good that the flag exists. Also enabling deprecated features in guile-1.6* caused some problems. From 1.6.7 ebuild: # Please keep --enable-deprecation=no in future bumps. # Danny van Dyk <kugelfang@gentoo.org 2004/09/19 from Changelog: 19 Sep 2004; Danny van Dyk <kugelfang@gentoo.org> +guile-1.6.4-r2.ebuild: Bumped to version 1.6.4-r2. This version is only necessary for gnucash on amd64. It disables deprecations that leave undefined references in shared libraries. I'm considering removing discouraged use flag since it is not independent of the deprecated flag, but it also isn't causing any problems, so there doesn't seem to be any great need either.
Moving app-office/gnotime to Bug 171141 which has a patch.
Okay, gnome-games is fixed. I really wish this wasn't necessary. Does this really mean you can't have gnome-games and gnucash on the same system?
gnucash-2.0.5 doesn't really need guile-1.8. In fact I can only compile it with guile-1.6.8.
(In reply to comment #16) > gnucash-2.0.5 doesn't really need guile-1.8. > In fact I can only compile it with guile-1.6.8. This doesn't matter at all until guile-1.6 and guile-1.8 share the same SLOT, which they do at the moment.. > It disables deprecations that leave undefined references in shared libraries. It leaves the impression that if user wants to have a well working gnucash, he needs to disable deprecated USE flag - on the other hand, if he wants to have gnome-games (which is, well, part of big gnome meta), he needs to have the deprecated USE flag enabled. How can one have both?
(In reply to comment #17) > This doesn't matter at all until guile-1.6 and guile-1.8 share the same SLOT, > which they do at the moment.. did you mean "unless" instead of "until" here? > > It disables deprecations that leave undefined references in shared libraries. where is this coming from? > It leaves the impression that if user wants to have a well working gnucash, he > needs to disable deprecated USE flag - on the other hand, if he wants to have > gnome-games (which is, well, part of big gnome meta), he needs to have the > deprecated USE flag enabled. > How can one have both? I'm not following you at all. Gnucash can use either guile-1.6.8 or guile-1.8.1 with deprecated use flag. The current ebuild for gnucash-2.0.5 depends on guile-1.8.1, but this is not strictly necessary and in fact I can't compile it that way.
(In reply to comment #18) > (In reply to comment #17) > > This doesn't matter at all until guile-1.6 and guile-1.8 share the same SLOT, > > which they do at the moment.. > > did you mean "unless" instead of "until" here? Yes > > > It disables deprecations that leave undefined references in shared libraries. > > where is this coming from? From comment #13 where you pasted a bit of the ChangeLog > > It leaves the impression that if user wants to have a well working gnucash, he > > needs to disable deprecated USE flag - on the other hand, if he wants to have > > gnome-games (which is, well, part of big gnome meta), he needs to have the > > deprecated USE flag enabled. > > How can one have both? > > I'm not following you at all. Gnucash can use either guile-1.6.8 or guile-1.8.1 > with deprecated use flag. Ok, good. comment #16 was just causing confusion then. I assume the problem (comment #13) for gnucash with deprecated stuff in guile is not an issue in 1.8 > The current ebuild for gnucash-2.0.5 depends on > guile-1.8.1, but this is not strictly necessary and in fact I can't compile it > that way. Above you said gnucash can use either.. Does it need deprecated USE flag then too, or what makes gnucash be able to use guile-1.8 for others?
(In reply to comment #19) > > The current ebuild for gnucash-2.0.5 depends on > > guile-1.8.1, but this is not strictly necessary and in fact I can't compile it > > that way. > > Above you said gnucash can use either.. Does it need deprecated USE flag then > too, or what makes gnucash be able to use guile-1.8 for others? I was having some problems myself compiling gnucash with guile-1.8.1, but I know now that they were caused by a broken g-wrap install. But whilst I didn't know that I tried to make it work with 1.6.8 and it worked. Opfer was having the same problem and confirms it works with 1.6.8. So I think you should ask seemant to make gnucash be able to use either 1.6.8 or 1.8.1.
