"openapp GWorkspace" fails. It opens two dialogs titled "Critical Error in GWorkspace" with the following msgs: NSInvalidArgumentException: NSConstantString(instance) does not recognize viewersForBaseNode: SInvalidArgumentException: GWViewerIconsPath(class) does not recognize initWithFrame: Here's what shows on the terminal if I ignore both errors: nilok@belladonna ~ $ openapp GWorkspace GWorkspace: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/libobjc/sendmsg.c:260: __objc_init_install_dtable: Assertion `(((Class)receiver)&&(((((Class)receiver)->info)&0x1L)==0x1L))' failed. Aborted I'm running ~x86 except that I have the following in /etc/portage/package.keywords: sys-libs/glibc -~x86 sys-devel/gcc -~x86 sys-devel/binutils -~x86 sys-devel/libtool -~x86 sys-kernel/development-sources -~x86 and /etc/portage/package.mask: >=dev-libs/libffi-3.4.1 This could be the cause of the bug because libffi-3.4.1-r* are in portage but it depends on gcc 3.4.x and thus I'm not using it. I'm posting this anyway for confirmation and because googling didn't turn up anything. emerge info: Portage 2.0.51_rc9 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6. 8.1 i686) ================================================================= System uname: 2.6.8.1 i686 Celeron (Coppermine) Gentoo Base System version 1.5.3 distcc 2.18 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.22 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3 /env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /us r/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ / usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/te xmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache collision-protection distcc distlocks sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.ccccom.com http://mirrors.tds.net/gentoo ftp://gentoo.mirrors.pai r.com/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d acpi alsa apm arts berkdb bitmap-fonts cjk crypt cups dga dvd eds e macs encode esd f77 faad fbcon fftw flac gcj gdbm gif gimpprint ginac gnome gpm gstreamer gtk gtk2 guile imlib jack java jpeg leim libg++ libwww live mad matros ka mikmod mmx mng motif mozilla mpeg ncurses nls objc offensive oggvorbis opengl oss pam pdflib perl plotutils png ppds python qhull qt quicktime radeon readlin e rtc scanner sdk sdl slang speex spell sse ssl svg tcltk tcpd tetex theora tiff truetype usb v4l wxwindows x86 xinerama xml xml2 xmms xosd xprint xv xvid zlib video_cards_mach64"
so what version of libffi are you using? there are also: - libffi-3.3.4.ebuild - libffi-3.3.3-r1.ebuild - libffi-3.3.4.ebuild ... which may interest you. :-) More info along those lines would be helpful. I've also updated libffi-3.3.3/4 to be more explicit about what versions of gcc must be installed.
Sounds like a valid bug, marking as NEW.
Sorry for the delay, for some reason I didn't receive emails about updates to this bug. I'm using libffi 3.3.4 because that is the most recent ebuild that works with gcc 3.3.4 (as I mentioned, I have gcc, glibc and a few others pinned to x86 and the rest of my system is ~x86). This problem is still happening with the newest gnustep-base, etc ebuilds from 2004-11-16. Actually, I wonder why I need libffi at all because I have built gcc with +gcj and from the description of libffi: "libffi (from gcc) does not commonly build unless gcj is compiled, but is used by other projects, like GNUstep." I can upgrade my system to gcc-3.4 and see if that fixes the problem.
I updated a bunch of gnustep ebuilds tonight. Things should be out to mirrors by now. One change was there's a "gcc-libffi" use flag for gnustep-base now. If you already emerged gcc with gcj, it should work. Just confirm that you are using any gcc with gcj with `gcc-config -l` (make sure it's the active profile), and try to emerge gnustep-base with that use flag. If things work, please let me know. FYI, >=gcc-3.4.3-r1 even installs libffi with objc (but this gcc ebuild is in testing, not really recommended right now).
For gnustep-base, in the ${DEPEND}, I changed the gcc dependency to 3.3.4 because that's what I'm running (gcc and glibc pegged on x86). || ( gcc-libffi? >=sys-devel/gcc-3.3.4-r1 >=dev-libs/libffi-3* ) If I didn't do this, then it still wanted to build libffi as a dependency. I will post later after all gnustep is rebuilt.
gnustep-make _requries_ that one compile gcc with objc support. "objc" USE flag in >=gcc-3.4.3-r1 now installs libffi, as gcj USE flag has done for a while. changing the depend will do nothing for you unless gcj is built. I'll have to look at the ebuild again to clear things up a bit, but knowing this now, you should be better off :-)
I understand you the first time. However, I do have gcc 3.3.4-r1 build with gcj and when I tried to emerge gnustep-base (with gcc-libffi use flag on), it wanted to build libffi as a dependency. So I looked at the ebuild and say this: || ( gcc-libffi? >=sys-devel/gcc-3.4.3-r1 >=dev-libs/libffi-3* ) But I'm not using gcc-3.4.3-r1! So I modified that line. If gnustep works with gcc-3.3.4-r1 with gcj use flag set, then perhaps there is an additional dependency that would satisfy things: (gcc-libffi && gjc)? >= sys-devel/gcc-3.3.4 (or something like that -- I'm not sure of the build notation to setup such a thing).
sorry, s/gjc/gcj/
What is the output of: - `gcc-config -l` - `find /usr/lib/gcc/ -name "*ffi*"`
nilok@aconite /usr/lib $ gcc-config -l [1] i686-pc-linux-gnu-2.95.3 [2] i686-pc-linux-gnu-3.3.4 * I don't have /usr/lib/gcc I assume you meant /usr/lib/gcc-lib? nilok@aconite find /usr/lib/gcc-lib/ -name "*ffi*" /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/fficonfig.h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/ffi.h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/ffi_mips.h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/java/awt/geom/AffineTransform.h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/javax/naming/InsufficientResourcesException.h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libffi.la /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libffi-2.00-beta.so /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libffi.so /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libffi.a
Heh, I actually meant "gcc", not "gcc-lib", but that's okay ... gcc-lib has been deprecated, forgot it used to be that. hrm...Things seem fine. Does this simple program compile for you? --snip-- ////// // Compile with: // gcc -o tryffi tryffi.c -lffi ////// #include <ffi.h> int main(void) { return 0; } --snip--
Yes that simple program works and even better so does GWorkspace.app!! So I guess we can close this bug. I still think the ebuild needs some modifications in the dependencies, because it doesn't seem to *need* gcc-3.4.3. gcc-3.3.4 seems to work fine. So logic like this perhaps: if gcc-libffi and gcj and objc is set then gcc-3.3.4 is ok. if gcc-libffi and objc is set then gcc-3.4.3 is ok. if no gcc-libffi then depend on libffi.
Excellent. I'm working on adding apprpriate messages to gnustep-make and gnustep-base to clarify all this for people. ...but just to clarify for me, what did you change to make gcc-3.3.4 work? You added gcj _and_ objc? So objc was missing at first? Thanks. (glad we got this solved!) :-)
I always had gcj and objc. The thing that made gworkspace work was to stop using libffi. things I never tried: 1) rebuilding gcc w/o gcj. 2) maybe the new gworkspace you introduced (20041203) would have fixed this bug *even* if I'd kept using libffi -- I never tried that. Why is libffi needed at all? Can you forget about libffi altogether and tell people to build gcc with objc (if they're using gcc 3.4) or to build gcc with gcj (and objc of course) if they're using gcc 3.3. Presumably gcc 3.4 will be stable by the time gnustep goes stable anyway? And since (I assume) you need objc to build gnustep, most people would never need libffi. Maybe gcc 3.3 ebuild could be version bumped in stable to make objc build the ffi stuff like it does in gcc 3.4. octave used to have a similar issue with fortran and the f77 use flag (now fortran use flag I think). If gcc was built with f77 then everytihng was ok, but if it wasn't you could depend on f2c. I think the situation is analogous here.
Yes, the situation sounds analogous ... I suppose the main difference is that 'gcj' adds a A LOT of time to the gcc compile, so I wanted to give people a choice. Sadly, the gcc-3.3.X series doesn't seem as "receptive" to the very very simple patch for gcc-3.4.X to make libffi compile seperately from 'gcj'. I'm okay requiring 3.4.X for only 'objc' to isntall libffi, 'cause in the end, 'gcj' does work, it just takes a longer time to compile.
fixed
Oh no! My other system (laptop) still exhibits this bug! The significant differences I can think of between the desktop (which this is fixed on) and the laptop is that the laptop runs Linux 2.6.9 instead of 2.4.28 and that the laptop has +ntpl for glibc. [ebuild R ] sys-devel/gcc-3.3.4-r1 +X -bootstrap -build -debug +fortran +gcj -hardened -multilib +nls +objc -pic -static (-uclibc) 0 kB [ebuild R ] gnustep-base/gnustep-base-1.10.2_pre20041203 -debug -doc +gcc-libffi -profile 0 kB [ebuild R ] gnustep-apps/gworkspace-0.6.6_pre20041203 -debug +pdfkit -profile 0 kB I've rebuild most of what I thought were the relevant dependencies of gworkspace and gnustep-base and the problem is still here. The output in comment #10 is the same except that the laptop doesn't have gcc 2.95 installed. The laptop also passes the "libffi.c" test in the ebuild I've rebuilt gcc (when f77 use flag became fortran), but i haven't rebuilt glibc since then - not sure if that could be related or not. This system uses distcc. I will turn that off and rebuild to see if it helps. emerge info: Portage 2.0.51-r8 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 Celeron (Coppermine) Gentoo Base System version 1.6.7 Python: dev-lang/python-2.3.4 [2.3.4 (#2, Oct 28 2004, 00:06:12)] distcc 2.18 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r2, 1.6.3, 1.7.9, 1.4_p6, 1.9.3 sys-devel/binutils: 2.15.90.0.1.1-r3 sys-devel/libtool: 1.5.10-r1 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3 /env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /us r/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ / usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/te xmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protection distcc distlocks san dbox sfperms userpriv usersandbox" GENTOO_MIRRORS="ftp://gentoo.ccccom.com ftp://ftp.ussg.iu.edu/pub/linux/gentoo h ttp://gentoo.ccccom.com http://gentoo.osuosl.org/ http://mirror.datapipe.net/gen too" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d acpi alsa apm arts berkdb bitmap-fonts cjk crypt cups dga dvd eds e macs encode esd f77 faad fam fbcon fftw flac fortran gcj gdbm gif gimpprint gina c gnome gnustep gpm gstreamer gtk gtk2 guile imagemagick imlib jack java jpeg le im libg++ libwww live mad matroska mikmod mmx mng motif mozilla mpeg ncurses nls nptl objc offensive oggvorbis opengl oss pam pdflib perl plotutils png ppds pyt hon qhull qt quicktime radeon readline rtc scanner sdk sdl slang speex spell sql ite sse ssl svg tcltk tcpd tetex theora tiff truetype usb v4l wxwindows x86 xine rama xml xml2 xmms xosd xv xvid zlib video_cards_mach64"
removing distcc from make.conf FEATURES and rebuilding gnustep-base and gworkspace didn't help.
I haven't committed that cvs.eclass patch yet (me and my computer out of commission for a few days). So have you forgotten to commit that cvs.eclass patch? I'll be updating it in a few hours, however.
I don't think this bug is in anyway related to the cvs.eclass patch from Bug #73482.
Could you try doing an `emerge --sync` (updated [but not bumped]) some ebuilds today, and try again? Remember to use userpriv and usersandbox, clear out /var/tmp/portage and make sure ownerships is "portage:portage" for /usr/src/distfiles/cvs-src/*. If things work, please post here, I thought we'd solved this. Thanks.
I followed Comment #11 and also unmerged every ebuild in /usr/portage/gnustep-*. Then I emerged gnustep-env and gworkspace. I then created a new user on my system (in case there was a problem in my ~/GNUstep). Problem still persists. Exactly the same dialogs and error messages as in Comment #1. List of differences between the desktop (where GWorkspace works) and my laptop (GWorkspace doesn't work): 1) Kernel 2.6 on laptop, 2.4 on desktop 2) +nptl in glibc on laptop, not on desktop 3) laptop CFLAGS="-O3 -march=i686 -fomit-frame-pointer" laptop CFLAGS="-march=athlon-xp -O3 -pipe" 4) Laptop is celeron (coppermine), desktop is athlon XP. Desktop has much more RAM 5) On laptop, I have not emerged glibc since last update to gcc (although, I don't think this is related because I did have +objc and +gcj when I build glibc) Maybe I'll just have to wait until gcc 3.4 goes stable (I guess this will happen around/before 2005.0) and see if that fixes the bug. But its very strange that it only shows up on one of my systems.
A bunch of gnustep ebuilds where updated a few days ago, including GWorksapce. I'm curious to know if this bug is closable or not. If you still want to test -- that'd be great. If not, please post here, as I still cannot reliably recreate some aspects of this bug, and I want to re-re-close it. ;-)
I'd like to help but until gnustep-back-art stops trying to downgrade my freetype to 2.1.5-r1, I can't really emerge gnustep: # emerge -pv gnustep-env These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] gnustep-base/gnustep-make-1.10.1_pre20050312 -debug -doc -layout-from-conf-file -layout-osx-like -non-flattened -profile 0 kB [ebuild N ] gnustep-base/gnustep-base-1.10.2_pre20050312 -debug -doc +gcc-libffi -profile 0 kB [ebuild N ] gnustep-base/gnustep-gui-0.9.5_pre20050312-r1 +cups -debug -doc +gif +gsnd +jpeg +png -profile 0 kB [ebuild N ] gnustep-libs/artresources-0.1.2 -debug -profile 1,439 kB [ebuild UD] media-libs/freetype-2.1.5-r1 [2.1.9-r1] -bindist +cjk -debug -doc +zlib 830 kB [ebuild N ] gnustep-base/mknfonts-0.5 -debug -profile 2 kB [ebuild N ] gnustep-base/gnustep-back-art-0.9.5_pre20050312 -debug -doc +opengl -profile -xim 0 kB [ebuild N ] gnustep-base/gnustep-env-0.1.6 -debug -profile 0 kB I see bug #84211 about this has been marked resolved but it doesn't look that way to me: # cat gnustep-back-art-0.9.5_pre20050312.ebuild | grep freetype >=media-libs/freetype-2.1.5 <media-libs/freetype-2.1.8
On my laptop, using a fresh gnustep/gworkspace install, I still see this bug. Errors seem a little different this time. It seems to get much further when launching GWorkspace. I first get some dialogs with the following messages: "The mtab path is not set. Using default value." and then "The mount points for removable media are not defined. Using default values." After that I get similar Critical Error dialogs almost like before: NSInvalidArgumentException: NSConstantString(instance) does not recognize GSDrawImage:: NSInvalidArgumentException: GWViewerIconsPath(class) does not recognize initWithFrame: and then on the console: GWorkspace: /var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/libobjc/sendmsg.c:260: __objc_init_install_dtable: Assertion `(((Class)receiver)&&(((((Class)receiver)->info)&0x1L)==0x1L))' failed. Aborted Note the first critical error now refers to GSDrawImage:: instead of viewersForBaseNode: On my desktop, using a fresh install, I also get the msgs about mtab and removable media but as before, no Critical Errors. So unfortunately, this bug is still out there! :-(
I am now using gcc-3.3.5-20050130. I've rebuild my gnustep setup and I can no longer reproduce this bug. Resolving to WORKSFORME.
