Re: help with libexif-gtk and cdrdao//udf-tools-1.0.0b3
On Wed, Dec 17, 2008 at 11:39:19PM +, Ken Moffat wrote: On Wed, Dec 17, 2008 at 08:43:39PM +, b-vol wrote: #then the not so good tidings: Ont the same AMD-64 (64-bit build gcc-4.3.2) udf-tools-1.0.0b3 dos not compile. I get the following compiler spew:- cdrwtool.c: In function 'cdrom_open_check': cdrwtool.c:606: error: 'INT_MAX' undeclared (first use in this function) cdrwtool.c:606: error: (Each undeclared identifier is reported only once cdrwtool.c:606: error: for each function it appears in.) I've seen that elsewhere, I think (checks notes ...) - also applies to dvd+rw-tools, add '#include limits.h' to that file (the userspace side of cdrom.h changed in 2.6.23). Oh, that's another appears to no longer be maintained package. We seem to have an awful lot of them in BLFS. For my sins, I was doing the need patches ticket, so I thought I'd have a go at udf-tools, but it's just one file after another. I've created ticket #2690 - I don't actually care about this package, so at the moment I'll be happy if it is put out of its misery and droped. (phrased that way because you never know, another dependency might drag it in). In the meantime, I recommend anyone who needs it to apply _all_ the patches / seds / whatever from a distro, and _only_ those changes. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao
On Wed, Dec 17, 2008 at 6:22 AM, Ken Moffat k...@linuxfromscratch.org wrote: On Tue, Dec 16, 2008 at 11:27:23PM +, b-vol wrote: Greetings, I am in a spot of bother with installing two programs on an AMD64 box (gcc-4.3.2 kernel 2.6.27.7 - 64-bit (non-multilib) build. (I've never come across libexif-gtk, and have no ideas about what is wrong. A quick search suggests distros are using it, so if nobody has any other suggestions you could try looking at the distros from http://oss-security.openwall.org/wiki/distro-patches - I think Dan gave me that link originally, It can be a bit hit-and-miss trying to find a path in some of them, but fedora (fc10) is usually a good place to start. I don't know if that will help.) Oooh, that's nice. I didn't give you that link, but I'm glad you posted it. Collects all the important information in one location instead of just floating around my head. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao
On Tue, Dec 16, 2008 at 3:27 PM, b-vol lux-in...@btconnect.com wrote: Greetings, I am in a spot of bother with installing two programs on an AMD64 box (gcc-4.3.2 kernel 2.6.27.7 - 64-bit (non-multilib) build. Program1:- libexif-gtk-0.3.5. This is needed for gtkam. gtkam (and libexif-gtk) are not in the blfs book but on the cblfs site. All attempts to compile libexif-gtk have failed. I tried the sed on the cblfs website as well as debian patches I found all to no avail. I tried stuff from the CVS repository but the downloaded stuff has no configure or autgen script.The first thing odd noticable is when running the configure script one gets (after makefile generation):- ./configure: line 29105: srcdir: command not found Configuration (libexif-gtk): Source code location: Version: 0.3.5 Compiler:gcc -m64 libexif: 0.6.12 (think about upgrading) I had libexif 0.6.16 and then 0.6.17 (newely relesed) installed and I still got the nonsence. Further down I get this:- libexif-gtk is looking for the exif-mem.h header file to determine if you have newer libexif. It should be in /usr/include/libexif/exif-mem.h. It looks like it's expecting `pkg-config --cflags libexif` to return -I/usr/include/libexif. Better would be to check for libexif/exif-mem.h. That's what the cblfs sed is doing. That should take care of this problem. In file included from gtk-menu-option.c:22: gtk-menu-option.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_menu_option_get_type' gtk-menu-option.c: In function 'gtk_menu_option_destroy': gtk-menu-option.c:72: warning: implicit declaration of function 'GTK_CHECK_CAST' gtk-menu-option.c:72: warning: nested extern declaration of 'GTK_CHECK_CAST' .. In file included from gtk-menu-option.c:22: gtk-menu-option.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_menu_option_get_type' gtk-menu-option.c: In function 'gtk_menu_option_destroy': gtk-menu-option.c:72: warning: implicit declaration of function 'GTK_CHECK_CAST' gtk-menu-option.c:72: warning: nested extern declaration of 'GTK_CHECK_CAST' Could you show the command being run and any other output before this? C errors can be tricky to debug. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao
On Tue, Dec 16, 2008 at 11:27:23PM +, b-vol wrote: Greetings, I am in a spot of bother with installing two programs on an AMD64 box (gcc-4.3.2 kernel 2.6.27.7 - 64-bit (non-multilib) build. (I've never come across libexif-gtk, and have no ideas about what is wrong. A quick search suggests distros are using it, so if nobody has any other suggestions you could try looking at the distros from http://oss-security.openwall.org/wiki/distro-patches - I think Dan gave me that link originally, It can be a bit hit-and-miss trying to find a path in some of them, but fedora (fc10) is usually a good place to start. I don't know if that will help.) Program 2:- cdrdao-1.2.2 TempFileManager.cc:84: error: 'strrchr' was not declared in this scope make[2]: *** [TempFileManager.o] Error 1 Please try http://www.linuxfromscratch.org/patches/downloads/cdrdao/cdrdao-1.2.2-gcc43_fixes-2.patch ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao//udf-tools-1.0.0b3
On Wednesday 17 December 2008 02:22:21 pm Ken Moffat wrote: On Tue, Dec 16, 2008 at 11:27:23PM +, b-vol wrote: Greetings, I am in a spot of bother with installing two programs on an AMD64 box (gcc-4.3.2 kernel 2.6.27.7 - 64-bit (non-multilib) build. (I've never come across libexif-gtk, and have no ideas about what is wrong. A quick search suggests distros are using it, so if nobody has any other suggestions you could try looking at the distros from http://oss-security.openwall.org/wiki/distro-patches - I think Dan gave me that link originally, It can be a bit hit-and-miss trying to find a path in some of them, but fedora (fc10) is usually a good place to start. I don't know if that will help.) Program 2:- cdrdao-1.2.2 TempFileManager.cc:84: error: 'strrchr' was not declared in this scope make[2]: *** [TempFileManager.o] Error 1 Please try http://www.linuxfromscratch.org/patches/downloads/cdrdao/cdrdao-1.2.2-gcc43 _fixes-2.patch ĸen -- das eine Mal als Tragödie, das andere Mal als Farce many thanks for your help:- #first good tidings: 1) for cdrcdao-1.2.2 the patch http://www.linuxfromscratch.org/patches/downloads/cdrdao/cdrdao-1.2.2-gcc43 worked well. 2) for libexif-gtk I will have to do some more digging. The program appears not to be well maintained. I am susprised it plays is such an important part for gtkam. If you or any other know of an alternative to gtkam please let me know. #then the not so good tidings: Ont the same AMD-64 (64-bit build gcc-4.3.2) udf-tools-1.0.0b3 dos not compile. I get the following compiler spew:- cdrwtool.c: In function 'cdrom_open_check': cdrwtool.c:606: error: 'INT_MAX' undeclared (first use in this function) cdrwtool.c:606: error: (Each undeclared identifier is reported only once cdrwtool.c:606: error: for each function it appears in.) make[1]: *** [cdrwtool.o] Error 1 make[1]: Leaving directory `/usr/src/build-08/vpn-08/sources-vpnc08/cdr-vpnc-08/udftools-1.0.0b3/cdrwtool' make: *** [all-recursive] Error 1 helpful suggestions will be welcomed sincerely lux-integ -- ### “Common sense teaches that booksellers should not speculate in hops, or bankers in turpentine; that railways should not be promoted by maiden ladies, or canals by beneficed clergymen ” Walter Bagehot-economist: 1826-1877 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao//udf-tools-1.0.0b3
On Wed, Dec 17, 2008 at 08:43:39PM +, b-vol wrote: #first good tidings: 1) for cdrcdao-1.2.2 the patch http://www.linuxfromscratch.org/patches/downloads/cdrdao/cdrdao-1.2.2-gcc43 worked well. great. It will get into BLFS-dev real soon now (I'm short of time at the moment, and beating my head against python/sip for kdebindings-4.1.3). 2) for libexif-gtk I will have to do some more digging. The program appears not to be well maintained. I am susprised it plays is such an important part for gtkam. If you or any other know of an alternative to gtkam please let me know. I'm not quite sure how it is used, but I see it is a front-end for gphoto2 (which doesn't impress me, I'm afraid). So, my usage is probably going to be slightly different from the way you want to work. I set up a rule for my camera in udev, an entry in /etc/fstab, then I just mount it and copy the files over (needs vfat in the kernel). Then, I use the gimp (and ufraw for raw files) to do manipulation, or sometimes I just use 'display' from ImageMagick. Not necessarily the most convenient way of looking at the pics (display will open them with pixels mapped 1:1), but then I normally have to do manipulations anyway, which is why I use the gimp. Alternatively, somebody will perhaps have a good word for gwenview (kde4 - again uses gphoto2), but in all honesty I think we've some way to go in sorting out how best to build kde4 at the moment. Maybe there are other front ends, I can certainly peopel mentioning that they use gphoto2. #then the not so good tidings: Ont the same AMD-64 (64-bit build gcc-4.3.2) udf-tools-1.0.0b3 dos not compile. I get the following compiler spew:- cdrwtool.c: In function 'cdrom_open_check': cdrwtool.c:606: error: 'INT_MAX' undeclared (first use in this function) cdrwtool.c:606: error: (Each undeclared identifier is reported only once cdrwtool.c:606: error: for each function it appears in.) I've seen that elsewhere, I think (checks notes ...) - also applies to dvd+rw-tools, add '#include limits.h' to that file (the userspace side of cdrom.h changed in 2.6.23). Oh, that's another appears to no longer be maintained package. We seem to have an awful lot of them in BLFS. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao//udf-tools-1.0.0b3
On Wed, Dec 17, 2008 at 3:39 PM, Ken Moffat k...@linuxfromscratch.org wrote: On Wed, Dec 17, 2008 at 08:43:39PM +, b-vol wrote: #first good tidings: 1) for cdrcdao-1.2.2 the patch http://www.linuxfromscratch.org/patches/downloads/cdrdao/cdrdao-1.2.2-gcc43 worked well. great. It will get into BLFS-dev real soon now (I'm short of time at the moment, and beating my head against python/sip for kdebindings-4.1.3). 2) for libexif-gtk I will have to do some more digging. The program appears not to be well maintained. I am susprised it plays is such an important part for gtkam. If you or any other know of an alternative to gtkam please let me know. I'm not quite sure how it is used, but I see it is a front-end for gphoto2 (which doesn't impress me, I'm afraid). So, my usage is probably going to be slightly different from the way you want to work. I set up a rule for my camera in udev, an entry in /etc/fstab, then I just mount it and copy the files over (needs vfat in the kernel). Then, I use the gimp (and ufraw for raw files) to do manipulation, or sometimes I just use 'display' from ImageMagick. Not necessarily the most convenient way of looking at the pics (display will open them with pixels mapped 1:1), but then I normally have to do manipulations anyway, which is why I use the gimp. Alternatively, somebody will perhaps have a good word for gwenview (kde4 - again uses gphoto2), but in all honesty I think we've some way to go in sorting out how best to build kde4 at the moment. Maybe there are other front ends, I can certainly peopel mentioning that they use gphoto2. I've been using libgphoto2 for a long time, and it works very well with my camera on the latest release. Another pretty simple GNOME gphoto frontend is gthumb. That's the default photo app on fedora and has a similar dependency set to gtkam. I think gtkam was more of an example frontend for gphoto when it was being developed. Nowadays, there are lots of them. Two that I've used are digiview and f-spot, although they'd take longer to get built. Even picasa uses gphoto via wine, I think. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with libexif-gtk and cdrdao
On Tue, 16 Dec 2008 23:27:23 +
b-vol lux-in...@btconnect.com wrote:
Greetings,
I am in a spot of bother with installing two programs on an AMD64
box (gcc-4.3.2 kernel 2.6.27.7 - 64-bit (non-multilib) build.
Program1:- libexif-gtk-0.3.5. This is needed for gtkam. gtkam (and
libexif-gtk) are not in the blfs book but on the cblfs site. All
attempts to compile libexif-gtk have failed. I tried the sed on
the cblfs website as well as debian patches I found all to no
avail. I tried stuff from the CVS repository but the
downloaded stuff has no configure or autgen script.The first
thing odd noticable is when running the configure script one
gets (after makefile generation):-
Not sure about AMD-64, but I am getting libexif-gtk 0.3.5 to build with
two patches, not sure if the same ones or not.
Applied the two attached patches:
patch -p0 libexif-0.6.13.patch
patch -p0 gtk212-fix.patch
autoreconf -f -i
Then normal configure and make.
I was getting the same error as you until I found a different gtk patch.
Working with Source Mage and not BLFS, but hope it helps.
George
--
George Sherwood
Source Mage GNU/Linux Lead Developer
http://www.sourcemage.org
--- configure.in.orig 2004-10-18 15:12:58.0 -0400
+++ configure.in 2006-01-05 19:06:05.0 -0500
@@ -52,7 +52,7 @@
dnl ---
CPPFLAGS_save=$CPPFLAGS
CPPFLAGS=$LIBEXIF_GTK_CFLAGS
-AC_CHECK_HEADER([exif-mem.h], [
+PKG_CHECK_MODULES(HAVE_EXIF_0_6_12, libexif = 0.6.12, [
exif_msg== 0.6.12
AC_DEFINE(HAVE_EXIF_0_6_12,1,[whether we use a version of libexif greater than 0.6.12])],[
exif_msg= 0.6.12 (think about upgrading)])
@@ -73,7 +73,7 @@
Configuration (${PACKAGE}):
- Source code location:$(srcdir)
+ Source code location:${srcdir}
Version: ${VERSION}
Compiler:${CC}
diff -ur gtk-extensions/Makefile.am gtk-extensions/Makefile.am
--- gtk-extensions/Makefile.am 2004-10-17 17:57:31.0 +0300
+++ gtk-extensions/Makefile.am 2007-10-04 17:39:01.0 +0300
@@ -1,7 +1,6 @@
INCLUDES =\
-I$(top_srcdir) \
-I$(top_srcdir)/intl \
- -DGTK_DISABLE_DEPRECATED \
$(GTK_CFLAGS)
noinst_LTLIBRARIES = libgtk-extensions.la
diff -ur libexif-gtk/Makefile.am libexif-gtk/Makefile.am
--- libexif-gtk/Makefile.am 2004-10-17 16:48:35.0 +0300
+++ libexif-gtk/Makefile.am 2007-10-04 17:39:32.0 +0300
@@ -3,8 +3,7 @@
-I$(top_srcdir)/intl\
-I$(top_srcdir)/gtk-extensions \
$(LIBEXIF_GTK_CFLAGS)\
- -DG_LOG_DOMAIN=\libexif\ \
- -DGTK_DISABLE_DEPRECATED
+ -DG_LOG_DOMAIN=\libexif\
lib_LTLIBRARIES = libexif-gtk.la
signature.asc
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
help with libexif-gtk and cdrdao
Greetings, I am in a spot of bother with installing two programs on an AMD64 box (gcc-4.3.2 kernel 2.6.27.7 - 64-bit (non-multilib) build. Program1:- libexif-gtk-0.3.5. This is needed for gtkam. gtkam (and libexif-gtk) are not in the blfs book but on the cblfs site. All attempts to compile libexif-gtk have failed. I tried the sed on the cblfs website as well as debian patches I found all to no avail. I tried stuff from the CVS repository but the downloaded stuff has no configure or autgen script.The first thing odd noticable is when running the configure script one gets (after makefile generation):- ./configure: line 29105: srcdir: command not found Configuration (libexif-gtk): Source code location: Version: 0.3.5 Compiler:gcc -m64 libexif: 0.6.12 (think about upgrading) I had libexif 0.6.16 and then 0.6.17 (newely relesed) installed and I still got the nonsence. Further down I get this:- In file included from gtk-menu-option.c:22: gtk-menu-option.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_menu_option_get_type' gtk-menu-option.c: In function 'gtk_menu_option_destroy': gtk-menu-option.c:72: warning: implicit declaration of function 'GTK_CHECK_CAST' gtk-menu-option.c:72: warning: nested extern declaration of 'GTK_CHECK_CAST' .. In file included from gtk-menu-option.c:22: gtk-menu-option.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_menu_option_get_type' gtk-menu-option.c: In function 'gtk_menu_option_destroy': gtk-menu-option.c:72: warning: implicit declaration of function 'GTK_CHECK_CAST' gtk-menu-option.c:72: warning: nested extern declaration of 'GTK_CHECK_CAST' Program 2:- cdrdao-1.2.2 The compiler spews out the folowing:- if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../pccts/h -I/opt/include -I/opt/include -I/opt/include -g -O2 -MT TempFileManager.o -MD -MP -MF .deps/TempFileManager.Tpo -c -o TempFileManager.o TempFileManager.cc; \ then mv -f .deps/TempFileManager.Tpo .deps/TempFileManager.Po; else rm -f .deps/TempFileManager.Tpo; exit 1; fi TempFileManager.cc: In member function 'bool TempFileManager::getTempFile(std::string, const char*, const char*)': TempFileManager.cc:84: error: 'strrchr' was not declared in this scope make[2]: *** [TempFileManager.o] Error 1 helpful suggestions will be appreciated lux-integ -- ### “Common sense teaches that booksellers should not speculate in hops, or bankers in turpentine; that railways should not be promoted by maiden ladies, or canals by beneficed clergymen ” Walter Bagehot-economist: 1826-1877 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
