Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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.