[Fink-users] solved: damn not this again
Okay, so I made it out. I noticed that the ___db185_open missing symbol was not referenced in the mc code, therefore it was being unresolved by the gnome metadata code in gnome-libs, which was the library that I duct taped by adding a -ldb. So I figured I better look back at that patch, and it turns out I made a mistake. I put -ldb when linking a test program, not the library itself. So all subsequent references to gnome-metadata primitives produced this link error. So basically I rebuilt gnome-libs with -ldb while linking libgnome itself, and the gnome libs test program and mc were both happy. I have two comments about stuff that does seem to be broken. Problem 1: I was reminded while doing a gratuitious "fink rebuild db3" that the db package actually seems messed up. Do that with db 3.3.11-6 and then build gnome-libs 1.4.1.4-3. Breakage: checking for dbopen... yes checking for db.h... no checking for db_185.h... no checking for db1/db.h... yes okay so far, barf on compile. It looks like it's using the wrong headers. I know there's a FAQ on this, BTW. Continuing: [localhost:/sw/src] root# ls -l /sw/include/db1/db.h -r--r--r-- 1 root wheel 57225 Jul 12 23:22 /sw/include/db1/db.h [localhost:/sw/src] root# ls -l /sw/include/db3/db.h -r--r--r-- 1 root wheel 57225 Jul 12 23:22 /sw/include/db3/db.h Hmm, looks like if I went sniffing in the db1 directory I would not be expecting to be finding a db3 header. So blindly let's try this: [localhost:/sw/src] cp /sw/include/db1/db_185.h /sw/include/db1/db.h Bang. It works. Looks to me either the db3 package needs rearranging, the gnome-libs package needs a better configure script, or both. But I'm not an expert as to which. Decide for yourself. Problem 2: libgnome's nonexistant -ldb. Add this to the 1.4.1.4-3 patch: diff -uN gnome-libs-1.4.1.4.old/libgnome/Makefile.in gnome- libs-1.4.1.4.new/lib\ gnome/Makefile.in --- gnome-libs-1.4.1.4.old/libgnome/Makefile.in Thu Jan 24 18:58:07 2002 +++ gnome-libs-1.4.1.4.new/libgnome/Makefile.inFri Jul 12 03:49:28 2002 @@ -234,7 +234,7 @@ EXTRA_DIST = parse-path.cP $(man_MANS) libgnome_la_LDFLAGS = -version-info 36:3:4 #-rpath $(libdir) -libgnome_la_LIBADD = $(GLIB_LIBS) -lm +libgnome_la_LIBADD = $(GLIB_LIBS) -lm -ldb bin_PROGRAMS = dns-helper gnome-dump-metadata gnome-moz-remote \ gconfigger gnome-gen-mimedb Okay, that's it. Sorry to be a pest today. Thanks for those of you who helped. Jeff Henrikson --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] damn not this again
Okay, this one is related to a FAQ (Q5.2: gnome-libs complains about dbopen and lots of other stuff.) The package mc-4.5.54-3 breaks: /usr/bin/ld: Undefined symbols: ___db185_open This is not because I don't have a db, or a db "without backward compatability", at least so far as I understand. It's just because the dumb makefile hasn't accumulated a -ldb from anywhere. I rebuilt db3 (3.3.11-6) but that doesn't help. (I knew it wouldn't, because it didn't with gnome-libs either.) Before I fixed gnome-libs by finding the targets that were linking with db and adding to the .patch file manual makefile edits to get -ldb in there. This is labor intensive and obviously addressing symptoms rather than problems. What's the cause? Jeff Henrikson --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] gdk-pixbuf error in build stage
Eh, never mind. I guess reinstalling gtk+-shlibs or some other intermediate futzing did joggle something. Sorry. Jeff --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] gdk-pixbuf error in build stage
Hi so more random breakage on my machine. Pardon my immediate complaining, I'm feeling very impatient with it at the moment. gdk-pixbuf breaks this time. It builds fine. Then when assembling the installation directory it fails trying to copy some .so files which don't exist: /bin/sh ./mkinstalldirs /sw/src/root-gdk-pixbuf-0.16.0-6/sw/share/aclocal mkdir /sw/src/root-gdk-pixbuf-0.16.0-6/sw/share/aclocal /usr/bin/install -c -m 644 ./gdk-pixbuf.m4 /sw/src/root-gdk- pixbuf-0.16.0-6/sw/share/aclocal/gdk-pixbuf.m4 install -d -m 755 /sw/src/root-gdk- pixbuf-0.16.0-6/sw/share/doc/gdk-pixbuf install -c -p -m 644 README COPYING* AUTHORS NEWS /sw/src/root-gdk-pixbuf-0.16.0-6/sw/share/doc/gdk-pixbuf/ rm -f /sw/src/root-gdk-pixbuf-0.16.0-6/sw/info/dir /sw/src/root-gdk-pixbuf-0.16.0-6/sw/info/dir.old /sw/src/root-gdk-pixbuf-0.16.0-6/sw/share/info/dir /sw/src/root-gdk-pixbuf-0.16.0-6/sw/share/info/dir.old rm -rf /sw/src/root-gdk-pixbuf-shlibs-0.16.0-6 mkdir -p /sw/src/root-gdk-pixbuf-shlibs-0.16.0-6/sw mkdir -p /sw/src/root-gdk-pixbuf-shlibs-0.16.0-6/DEBIAN install -d -m 755 /sw/src/root-gdk-pixbuf- shlibs-0.16.0-6/sw/lib/gdk-pixbuf/loaders mv /sw/src/root-gdk-pixbuf-0.16.0-6/sw/lib/gdk-pixbuf/loaders/*.so /sw/src/root-gdk-pixbuf-shlibs-0.16.0-6/sw/lib/gdk-pixbuf/loaders mv: rename /sw/src/root-gdk-pixbuf-0.16.0-6/sw/lib/gdk- pixbuf/loaders/*.so to /sw/src/root-gdk-pixbuf- shlibs-0.16.0-6/sw/lib/gdk-pixbuf/loaders/*.so: No such file or directory Maybe this has to do with these suspicious error messages during build? No gdk shared libs? I don't think so. *** Warning: This library needs some functionality provided by -lgdk. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libpixbufloader-tiff. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru .libs/libpixbufloader-tiff.a io-tiff.o ranlib .libs/libpixbufloader-tiff.a creating libpixbufloader-tiff.la There are no strange failures in the configure tests that I can notice, all the basics seem to happen: checking for glib-config... /sw/bin/glib-config checking for GLIB - version >= 1.2.0... yes checking for gtk-config... /sw/bin/gtk-config checking for GTK - version >= 1.2.0... yes I don't see an explicit tests for shared libs. An explict "fink reinstall gtk+-shlibs" does not remedy anything. As usual, help (even in the form of "hey dumbass") would be greatly appreciated. Incidentally, is it possible that between all my fink selfupdates and broken installs/reinstalls I have concocted myself a possessed machine? How likely would nuking all of /sw and starting over be toward solving these problems. Or does every user of stable/main experience a comparable number of difficulties? I seem to get very many considering the uniformity of OS X machines as compared to, say, linux boxes. Jeff --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] gnome-print dependencies
(incidentally, I was able to successfully duct tape my gnome-libs .patch file, still interested in general info but immediate need met) New issue: can somebody please clarify the following: budle-gnome causes a gnome- print-0.35-3 install, which crashes with: checking for gdk-pixbuf-config... /sw/bin/gdk-pixbuf-config checking for GDK_PIXBUF - version >= 0.7.0... no *** Could not run GDK_PIXBUF test program, checking why... *** The test program compiled, but did not run. This usually means *** that the run-time linker is not finding GDK_PIXBUF or finding the wrong *** version of GDK_PIXBUF. If it is not finding GDK_PIXBUF, you'll need to set your *** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point *** to the installed location Also, make sure you have run ldconfig if that *** is required on your system *** *** If you have an old version installed, it is best to remove it, although *** you may also be able to get things to work by modifying LD_LIBRARY_PATH According to the "package" link off of fink.sourceforge.net, there doesn't even exist a fink package for gdk-pixbuf past version 0.18 in unstable. What gives? Jeff Henrikson --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] libgnome breakage
Hi, I have a specific problem and general question about such problems. My specific problem: I "fink install gnome-libs and get breakage linking one of the target objects: /usr/bin/ld: Undefined symbols: ___db185_open make[2]: *** [gnome-dump-metadata] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 ### make failed, exit code 2 Failed: compiling gnome-libs-1.4.1.4-3 failed Now I know this _not_ to be a problem with my db package, I've installed/reinstalled that like five times manually and now with the fink package to get it working. Right now I can see what the problem is, there's no -ldb on the command line: cc -O3 -Wall -Wunused -L/sw/lib -o .libs/gnome-dump-metadata -L/sw/lib -lglib gnome-dump.o -L.libs -lgnome -lglib -lm -lz -lm -L../support/.libs -lgnomesupport -lz -lm -L/sw/lib -lesd -laudiofile -lm -L/sw/lib -laudiofile -lm -L/sw/lib -lglib -lintl -lz -lm Though I am not an automake expert, it looks like there must be an error in the Makefile.am in that directory. So my specific question, obviously: what can I do to get the package installed? My general question is regarding that for whatever reason, package breakage seems to be a common occurrence on my machine, and often I can see what the problem is. So generally speaking, what can I do to fix these things, short of learning how to assemble a package, editing the .patch and or .info, and rerunning the installer? If I am able to just edit the files in place and complete the build manually, is there a way tell the packager to resume? What easy way is there to get a patch without deleting all the temporary targets (or do I just copy the tree, make clean and go with that? What about deleting all the autoconf-produced files and etc?) Once I have a patch, should I lie to my system and overwrite an old .patch file in the fink directories, or should I make up a new version number? How? Jeff Henrikson --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf ___ Fink-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] Fink gdk-pixbuf version mismatch problem
Mr. Morrison, Thanks for the help, I would have responded sooner but your email didn't land in my inbox somehow. I only found it by searching the list archives. Anyway, two months ago you gave me this advice. I ran the version check numbers and still got 0.0.0. I apparently have the right source tarballs and patches, and rebuilding yields yet another shared lib with version 0.0.0. The output of all that is after your email. If you can make any sense of it, I would appreciate it. I also tried rebuilding the package gdk-pixbuf-shlibs and it doesn't change the version listed for "otool -L /sw/lib/libgdk_pixbuf.2.dylib" either. Still 0.0.0. Regards, Jeff Henrikson From: David R. Morrison Subject: [Fink-users] Re: version mismatch for library Date: Sat, 23 Mar 2002 04:17:48 -0800 Jeff Henrikson wrote: > Somehow I "upgraded" libgdk_pixbuf and now get an error > running Gnome panel or anything else that uses it: > > > dyld: panel-real version mismatch for > library:/sw/lib/libgdk_pibuf.2.dylib (compatability version > of user: 3.0.0 greater than library's version: 0.0.0) > > > Somewhere in the fink docs I read that 0.0.0 is somesort of > wildcard signifier. Does dyld understand this? Where is > this version number stored? What does the .la libtool > version have to do with it? You can determine the version number by running "otool -L /sw/lib/libgdk_pixbuf.2.dylib" and looking for libgdk_pixbuf in the output. The version numbers needed by other programs and libraries will be in their own "otool -L" output. These numbers are fixed when the libraries and binaries are created. I'm not sure exactly what 0.0.0 is supposed to do; I've seen some indications that it should be avoided completely. Why version of the gdk_pixbuf package do you have installed? (You can determine this easily with "dpkg -l gdk-pixbuf".) I have the latest version from the unstable tree, gdk-pixbuf-0.16.0-3, and the version numbers I get from that are 3.0.0. You might try copying that into our fink "local" tree and then rebuilding gdk-pixbuf. -- Dave bash2.05 jehenrik@localhost ~/new % otool -L /sw/lib/libgdk_pixbuf.2.dylib /sw/lib/libgdk_pixbuf.2.dylib: /sw/lib/libgdk_pixbuf.2.dylib (compatibility version 0.0.0, current version 0.0.0) /sw/lib/libgmodule-1.2.0.dylib (compatibility version 1.0.0, current version 1.10.0) /sw/lib/libglib-1.2.0.dylib (compatibility version 1.0.0, current version 1.10.0) . . . bash2.05 jehenrik@localhost ~/new % sudo fink rebuild gdk-pixbuf Reading package info... Information about 765 packages read in 5 seconds. pkg gdk-pixbuf version ### pkg gdk-pixbuf version 0.16.0-3 The following package will be rebuilt: gdk-pixbuf mkdir -p /sw/src/gdk-pixbuf-0.16.0-3 bzip2 -dc /sw/src/gdk-pixbuf-0.16.0.tar.bz2 | tar -xvf - gdk-pixbuf-0.16.0/ . . . gdk-pixbuf-0.16.0/doc/html/x3787.html patch -p1 https://lists.sourceforge.net/lists/listinfo/fink-users
