The new libexif seems to provide two way of retrieving the value :
return value using a (const char*) or by passing a char * parameter with a int 
in the third and fourth paramrs of the function.

The function is encapsulated in a g_strdup call so I think the best fix is to 
pass a NULL pointer and 0 as the missing params

exif_content_get_value (content, tag, NULL, 0)

Of course, this won't work with older version of libexif so a test on the 
version number will be required.

It works with me (Nautilus CVS and libexif 0.6.9 Debian GNU/Linux unstable)
Cheers

with a 0/NULL for the missing param you get nautilus crashing on file properties
for images with exif datas ... 

I've tried with 4096 as value, it seems to be ok (at least it doesn't crash
anymore), but I'm not sure it's a good value to use.

in fact the 4096 was not for this problem. I don't know how to fix this crash
for the moment.

This fix works here (not sure for the 4096 value)

---
nautilus-2.6.3.orig/components/image_properties/nautilus-image-properties-view.c
   2004-03-09 12:27:53.000000000 +0100
+++ nautilus-2.6.3/components/image_properties/nautilus-image-properties-view.c
2004-06-30 14:41:20.000000000 +0200
@@ -124,13 +124,14 @@
 exif_content_callback (ExifContent *content, gpointer data)
 {
        struct ExifAttribute *attribute;
+       char val[4096];

        attribute = (struct ExifAttribute *)data;
        if (attribute->found) {
                return;
        }

-        attribute->value = g_strdup (exif_content_get_value (content,
attribute->tag));
+        attribute->value = g_strdup (exif_content_get_value (content,
attribute->tag, val, 4096));
        if (attribute->value != NULL) {
                attribute->found = TRUE;
        }

I was having the same problem when didn't manage to file this solution until 5 
min despite doing SEVERAL previous searches.... Anyways, the patch appears to 
work even with version Nautilus-2.7.2 and compiles. Had to manually edit, diff 
kept giving ***malformed header at line 5 errors or something to that effect...

whoops, correction... I was having the same problem but didn't manage to fine 
this solution until approx. 5mins ago despite several searches... adios

*** Bug 152676 has been marked as a duplicate of this bug. ***

this bug still exists in version 2.8.1 the patch also works on this version. It
solved my compilation problem

Created attachment 32764 [details] [review]
nautilus-libexif6.patch

Better patch, which does not break 0.5.12 support. Eog uses 1024, which is far
enough for informative entry string length. Is it possible to commit the patch?
Nautilus is one of the last show-stoppers for new libexif.

Created attachment 32766 [details] [review]
nautilus-libexif6.patch

Version with better config.h comments (not yet used by nautilus).

*** Bug 149354 has been marked as a duplicate of this bug. ***

Tried patch on Nauilus 2.8.1 and it caused it to fail when building against
0.5.12.  When I updated libexif to 0.6.11 it compiled without error.

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DG_LOG_DOMAIN=\"Nautilus-Image-Properties\"
-DDATADIR=\"/usr/share\" -I../.. -I../.. -pthread -DORBIT2=1
-I/usr/include/eel-2 -I/usr/include/gconf/2 -I/usr/include/gtk-2.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libart-2.0
-I/usr/include/libgnome-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libxml2
-I/usr/include/gail-1.0 -I/usr/include/libglade-2.0 -I/usr/include/orbit-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/include/libbonobo-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/libbonoboui-2.0
-I/usr/include/gnome-vfs-module-2.0 -I/usr/include/gnome-desktop-2.0
-I/usr/include/startup-notification-1.0 -I/usr/include/libexif -O
-march=athlon-mp -mmmx -mfpmath=sse -msse -m3dnow -pipe -O3 -c
nautilus-image-properties-view.c  -fPIC -DPIC -o
.libs/nautilus-image-properties-view.o
nautilus-image-properties-view.c:139:99: macro "exif_content_get_value" passed 4
arguments, but takes just 2
nautilus-image-properties-view.c: In function `exif_content_callback':
nautilus-image-properties-view.c:139: error: `exif_content_get_value' undeclared
(first use in this function)
nautilus-image-properties-view.c:139: error: (Each undeclared identifier is
reported only once
nautilus-image-properties-view.c:139: error: for each function it appears in.)
make[4]: Leaving directory `/usr/src/nautilus-2.8.1/components/image_properties'
make[4]: *** [nautilus-image-properties-view.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/nautilus-2.8.1/components'
make[2]: Leaving directory `/usr/src/nautilus-2.8.1'
make[2]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/nautilus-2.8.1'
make[1]: *** [all-recursive-am] Error 2

Why don't we simply depend on 0.6.10 instead of doing some config.h voodoo?
It has been out for around two months.

http://sourceforge.net/mailarchive/forum.php?thread_id=3726141&forum_id=8715

To Robin Cook: Did you run autoreconf (or run configure
--enable-maintainer-mode)? Works for me with both 0.5.12 and 0.6.x.

To Christian - Manny Calavera - Neumair: Because Nautilus 2.8.1 can be compiled
only with libexif==0.5.12. And because eog does the same.

*** Bug 157423 has been marked as a duplicate of this bug. ***

The bug is still present in nautilus-2.9.2.

fixed in the CVS:

2005-01-27  Chris Lahey  <clahey@ximian.com>

        * acconfig.h, configure.in, src/nautilus-image-properties-page.c:
        Support the API change in libexif > 0.5.12.