libexif-devel — This is the place where your questions about libexif will be answered.

[Libexif-devel] compile on win32 with MSVC60

[lode l. <lod...@ho...>]

Hi folks,

I posted a patch to compile libexif with MSVC60.
The patch is trivial and should (IMHO) be applied to the mainline as well...

the fixes add some code dependencies on values defined in config.h
(ENABLE_NLS,GETTEXT_PACKAGE) but are not properly used throughout the code
(since these are enabled by default on *nix)

http://sourceforge.net/tracker/index.php?func=detail&aid=871679&group_id=12272&atid=312272

_________________________________________________________________

Re: [Libexif-devel] Missing Initialization

[Lutz <lu...@us...>]

On Fri, 2003-12-26 at 23:12, Antonio Scuri wrote:
>    The following tags were missing in exif_entry_initialize at exif-ent=
ry.c:
>=20
> 	EXIF_TAG_FLASH
>            EXIF_TAG_MAKER_NOTE:
>            EXIF_TAG_COMPONENTS_CONFIGURATION
>            EXIF_TAG_COLOR_SPACE
> 	EXIF_TAG_ISO_SPEED_RATINGS
> 	EXIF_TAG_PIXEL_X_DIMENSION
> 	EXIF_TAG_PIXEL_Y_DIMENSION
> 	EXIF_TAG_SPECTRAL_SENSITIVITY
> 	EXIF_TAG_SUBSEC_TIME		=09
> 	EXIF_TAG_SUB_SEC_TIME_ORIGINAL	=09
> 	EXIF_TAG_SUB_SEC_TIME_DIGITIZED	=09
> 	EXIF_TAG_OECF			=09
> 	EXIF_TAG_SPATIAL_FREQUENCY_RESPONSE
> 	EXIF_TAG_NEW_CFA_PATTERN	=09
> 	EXIF_TAG_DEVICE_SETTING_DESCRIPTION=09
> 	EXIF_TAG_SUBJECT_AREA		=09
> 	EXIF_TAG_RELATED_SOUND_FILE	=09
> 	EXIF_TAG_IMAGE_UNIQUE_ID	=09
>=20
>    Some strings are initialized with "[None]", but this is not in the=20
> specs, are they? I guess a better initialization is simply to put 0 and=
 let=20
> the user test for "entry->components =3D=3D 0" to initialize the missin=
g values.

Hello Antonio!

Thanks for spending time on libexif. Could you convert your suggestions
into patches and send them to us? If possible, please use 'cvs diff -u3
-p'.=20

Regards
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Missing Initialization

[Antonio S. <sc...@te...>]

   The following tags were missing in exif_entry_initialize at exif-entry.c:

	EXIF_TAG_FLASH
           EXIF_TAG_MAKER_NOTE:
           EXIF_TAG_COMPONENTS_CONFIGURATION
           EXIF_TAG_COLOR_SPACE
	EXIF_TAG_ISO_SPEED_RATINGS
	EXIF_TAG_PIXEL_X_DIMENSION
	EXIF_TAG_PIXEL_Y_DIMENSION
	EXIF_TAG_SPECTRAL_SENSITIVITY
	EXIF_TAG_SUBSEC_TIME			
	EXIF_TAG_SUB_SEC_TIME_ORIGINAL		
	EXIF_TAG_SUB_SEC_TIME_DIGITIZED		
	EXIF_TAG_OECF				
	EXIF_TAG_SPATIAL_FREQUENCY_RESPONSE
	EXIF_TAG_NEW_CFA_PATTERN		
	EXIF_TAG_DEVICE_SETTING_DESCRIPTION	
	EXIF_TAG_SUBJECT_AREA			
	EXIF_TAG_RELATED_SOUND_FILE		
	EXIF_TAG_IMAGE_UNIQUE_ID		

   Some strings are initialized with "[None]", but this is not in the 
specs, are they? I guess a better initialization is simply to put 0 and let 
the user test for "entry->components == 0" to initialize the missing values.

Best,
Antonio Scuri

[Libexif-devel] Usage with libjpeg 6

[Antonio S. <sc...@te...>]

   Hi,

   I downloaded version 0.5.12 and I sucessfully use it together with 
libjpeg 6. The lack of documentation was a small problem, the API is simple 
enough to implement all I need in a couple of calls. Great job.

   If someone is interested I can send the code code.

   I also had make some changes to compile it.

   First, you have a config.h file too complex, for a so simple library. I 
guess it could be simplified. I build it using cygwin, then I build one 
from scratch for Visual C++ using the other as a reference. It works fine.

    In fact I notice that only 2 definitions from config.h are used in the 
code ENABLE_NLS and GETTEXT_PACKAGE. The first one I disable since I am not 
using gettext.

   Then, exif-loader.c depends on jpeg-marker.h, since I am only using 
libexif code I had to copy that header. But the jpeg folder was very 
usefull to help me understand the library.

   Finaly the snprintf function used in exif-entry.c is not ANSI C, so it 
would be nice if replaced by sprintf or other. The Visual C++ only defines 
"_snprintf". I don't use the dump functions but this it will make the 
library more portable.

Best,
Antonio Scuri

[Libexif-devel] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoGyhCICAbJEI0WD80JE5MNSQkGyhC?= =?ISO-2022-JP?B?GyRCSn0kSyRPJCo8aj90JEckOSQsOm89fCRyJCo0aiQkPz0kNz5lGyhC?= =?ISO-2022-JP?B?GyRCJDIkXiQ5ISMbKEI=?=

[<aaa...@fr...>]

未承諾広告※  関心の無い方にはお手数ですが削除をお願い申し上げます。
＊送信者：大野和子
＊事業者：AAA-network Co.,Ltd.
　東京都目黒区目黒3-4-16／ＴＥＬ：0120−77−5869
※当方からのメールがご迷惑な方には、お手数ですが『受信拒否』と表示
　して inf...@3-...   までメールを返信して下さい。
※拒否メール受信後、3日以内にメールアドレスを除去致します。
※複数アドレスを受信拒否希望の方は、お手数ですが対象アドレスを全て
　メッセージ内に表示していただければ除去いたします。
  私どもは、他用・流出は一切いたしません。

★在宅（SOHO・パソコン)ワークスタッフ募集のご案内です★

◎余暇を利用して副収入を得られたら
◎どうしても家を空けられない
◎人間関係がうまくいかない
◎地方ということで仕事が思うようにならない
◎将来が不安なので、今のうちに
などとお考えの方

今後ますます日本経済状況は悪化し今となってはもう会社も社員を守って
くれないのが現実です。
今までの就業スタイルでは諦めるしかなかった主婦や高齢者の方々にも、
在宅ワークは大きなチャンスとして注目されています。
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆
◎１日２〜３時間程度なら時間が取れる方であれば、初級レベルのデータ
入力のお仕事であれば4・5万前後の収入に成ります。それ以外にもお仕事
は有りますが良く聞かれるご質問として、
どのような仕事があるの？＝ＩＴ系以外の在宅で出来る仕事からもできま
す。私共は登録者が安定した副収入を取れるようにということを優先して
おり、その為、請け負う仕事をパソコンでの在宅ワーク以外に、手作業の
在宅ワークや派遣業務に至るまで幅広く取り揃えていき、皆様にバラつき
のないお仕事の情報提供にお応えして参ります。

将来安定に向けてご自身の技能を活用して、副収入を得る機会としてご案
内しております。
全くパソコン未経験の方でもやる気さえあればパソコン業務以外のお仕事
から副収入を得ていただけます。
業務は、誰でも出来る宛名書きから、データ入力・文章入力・HP作成・イ
ラスト・DTP・Flash画面作成等々まで幅広くあり、毎週さまざまなお仕事
情報を配信しております。

現在、20歳〜60歳の主婦・フリーター・会社員の方々が余暇を活用しなが
ら活躍しております。

★詳しくは下記ホームページで資料請求(無料)のうえご確認下さい★
〈資料請求の手順〉
1.　URL『http://www.3-aaa.net』へアクセス
2. 『トップ』〜『資料請求』
3.　フォームに従って必要事項の入力
4.  このメールをご覧の方はエリアコード『012』を選択
5.  入力完了後『送信』
 　
※この広告が３日以内に重複した場合は、決して悪意はございませんので
　ご容赦下さい。拒否者のアドレス除去は十分注意して参ります。
※代理店が数社あり、重複いたしましたらご容赦下さい。情報交換が不可
　能な為、ご迷惑をおかけして申し訳ございませんが、受信拒否希望の方
　はお手数ですが、各送信先に受信拒否として自動返信いただくか、着信
　拒否の設定をお願い申し上げます。

Re: [Libexif-devel] Re: libmnote and libexif merged

[Roberto C. <rob...@en...>]

Lutz Müller wrote:
> 
> On Tue, 2003-11-04 at 21:52, Roberto Costa wrote:
> > Perhaps it should be possible for a library client to request one of the
> > two behaviours explicitly, unless specified the exif data compaction
> > would be enabled for known maker notes and disabled for the others.
> >
> > Have you in mind an interface to do it?
> 
> I don't think anyone cares for the possibility to switch between storing
> the original EXIF data in addition to our new one and not doing so. It
> should just work. If someone really needs the feature, we can add it
> easily later.

Well, I do care, this is why I was suggesting it ;-)
More in general, since libexif is a public library, which happens to
know how to do a particular job (saving exif data in our case) in two
different ways, I think the user should be able to choose which way he
wants to do things.
This makes especially sense to me if I consider that there is a trade
off, one method is more conservative, the other produces smaller and
more compact exif data.

Cheers,
Roberto

Re: [Libexif-devel] Re: libmnote and libexif merged

[Lutz <lu...@us...>]

On Tue, 2003-11-04 at 21:52, Roberto Costa wrote:
> Perhaps it should be possible for a library client to request one of th=
e
> two behaviours explicitly, unless specified the exif data compaction
> would be enabled for known maker notes and disabled for the others.
>=20
> Have you in mind an interface to do it?

I don't think anyone cares for the possibility to switch between storing
the original EXIF data in addition to our new one and not doing so. It
should just work. If someone really needs the feature, we can add it
easily later.
--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Re: libmnote and libexif merged

[Roberto C. <rob...@en...>]

Lutz M=FCller wrote:
>=20
> On Mon, 2003-11-03 at 21:04, Roberto Costa wrote:
> > Lutz M=FCller wrote:
> > I'm not convinced that is an acceptable behaviour the fact that a
> > libexif user that processes his/her images with the library may lose
> > information because of lack of knowledge about his/her camera maker
> > notes.
> > My idea is that libexif should always be conservative and do its best
> > not to corrupt any user exif info.
>=20
> Agreed. So, if we encounter MakerNotes other than Canon, Olympus and
> Pentax, we'd like to preserve data between IFDs at its original offsets=
=2E
> The easiest way (I guess) to accomplish that would be to preserve the
> original EXIF data, to append our new/modified EXIF data at the end and
> simply point in the EXIF header to our new IFD0...

Yes, I fully agree.
Perhaps it should be possible for a library client to request one of the
two behaviours explicitly, unless specified the exif data compaction
would be enabled for known maker notes and disabled for the others.

Have you in mind an interface to do it?
I guess it would be sufficient to add a new function to save exif data,
the signature would be identical to the existing except for an
additional parameter that specifies the desired behaviour.

Cheers,
Roberto

Re: [Libexif-devel] Re: libmnote and libexif merged

[Lutz <lu...@us...>]

On Mon, 2003-11-03 at 21:04, Roberto Costa wrote:
> Lutz M=FCller wrote:
> I'm not convinced that is an acceptable behaviour the fact that a
> libexif user that processes his/her images with the library may lose
> information because of lack of knowledge about his/her camera maker
> notes.
> My idea is that libexif should always be conservative and do its best
> not to corrupt any user exif info.

Agreed. So, if we encounter MakerNotes other than Canon, Olympus and
Pentax, we'd like to preserve data between IFDs at its original offsets.
The easiest way (I guess) to accomplish that would be to preserve the
original EXIF data, to append our new/modified EXIF data at the end and
simply point in the EXIF header to our new IFD0...

--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Re: libmnote and libexif merged

[Roberto C. <rob...@en...>]

Lutz Müller wrote:
> 
> On Thu, 2003-10-30 at 22:14, Roberto Costa wrote:
> > I haven't had yet enough time to look at it closely as I would like to,
> > in the meantime a couple of questions naturally come into my mind:
> > What happens to a picture with a maker note not recognized by libexif?
> 
> libexif keeps the data in the MakerNote. If any data is stored somewhere
> else, it will be lost.

I'm not convinced that is an acceptable behaviour the fact that a
libexif user that processes his/her images with the library may lose
information because of lack of knowledge about his/her camera maker
notes.
My idea is that libexif should always be conservative and do its best
not to corrupt any user exif info. When it's not the case, I think at
least the user should be clearly warned of the risks derived from using
libexif.
 
> By the way, if you save MakerNotes that are recognized by libexif, all
> data is now stored in the MakerNote tag (as it should have been from the
> very beginning).

I agree that it is a big mistake, nevertheless exif specs don't say that
MakerNote tag must be self-contained and that it can't refer to data
allocated outside its boundaries.
I think it's a bug in the specs we should deal with.

Cheers,
Roberto

Re: [Libexif-devel] Python wrapper for libexif?

[Fred L. D. Jr. <fd...@ac...>]

Lutz M=FCller writes:
 > It demonstrates how to create and modify EXIF data, how to save it
 > (exif_data_save_data), and how to load it (exif_loader). This is pre=
tty
 > much all libexif is able to do.

Ok, then I'll need to spend some time reading up.

 > I'd look at exif. There, you don't have the gtk overhead. gexif is m=
ore
 > or less a demonstration for libexif-gtk which I wrote in the hope it=

 > gets picked up by the GIMP or other gtk programs.

Ok, sounds like a good plan.

 > gtk-doc is, in my opinion, not suited for this small library. But I
 > don't know other tools.

Ah, tools.  I agree about gtk-doc.  Whether that's reason to avoid it
I don't know; that depends on how closely you'd like the library to be
associated with the glib/gtk world.  I'd have to thing about what's
good.  There are a number of tools supporting documentation embedded
in C/C++, but most of them have a strong leaning toward the C++ side,
so making something presentable for a C library may take a lot of
tweaking.  I'll think about this a bit; I'd like to find a better
solution for Expat as well.  (For Expat, we currently have one big
XHTML file; it's rather a pain to work with.)


  -Fred

--=20
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Re: [Libexif-devel] Python wrapper for libexif?

[Lutz <lu...@us...>]

On Thu, 2003-10-30 at 22:34, Fred L. Drake, Jr. wrote:
> Hmm.  I'm looking at the 0.5.12 release.  test/ includes test-tree.c,
> which only uses the JPEG code,

Forget that.

> and test-mem.c, which is fairly small
> and doesn't use a lot of the library (or doesn't appear to).

It demonstrates how to create and modify EXIF data, how to save it
(exif_data_save_data), and how to load it (exif_loader). This is pretty
much all libexif is able to do.

> I've picked up gexif, but haven't had time to dig into the sources.

I'd look at exif. There, you don't have the gtk overhead. gexif is more
or less a demonstration for libexif-gtk which I wrote in the hope it
gets picked up by the GIMP or other gtk programs.

>  > How would you like the documentation to be?
>=20
> Complete and well-written, of course!  ;-)  How to get there from
> what's in 0.5.12, I don't know yet.

gtk-doc is, in my opinion, not suited for this small library. But I
don't know other tools.

--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Python wrapper for libexif?

[Fred L. D. Jr. <fd...@ac...>]

Lutz M=FCller writes:
 > Don't you like the header files? :-)

They're very nice header files.  I'm sure I'll get along with them
just fine.  ;-)

 > The programs in libexif/test demonstrate pretty well how to use libe=
xif.

Hmm.  I'm looking at the 0.5.12 release.  test/ includes test-tree.c,
which only uses the JPEG code, and test-mem.c, which is fairly small
and doesn't use a lot of the library (or doesn't appear to).  Have the
tests been extended in CVS?

I've picked up gexif, but haven't had time to dig into the sources.

 > How would you like the documentation to be?

Complete and well-written, of course!  ;-)  How to get there from
what's in 0.5.12, I don't know yet.


  -Fred

--=20
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

[Libexif-devel] Re: libmnote and libexif merged

[Lutz <lu...@us...>]

On Thu, 2003-10-30 at 22:14, Roberto Costa wrote:
> I haven't had yet enough time to look at it closely as I would like to,
> in the meantime a couple of questions naturally come into my mind:
> What happens to a picture with a maker note not recognized by libexif?

libexif keeps the data in the MakerNote. If any data is stored somewhere
else, it will be lost.

By the way, if you save MakerNotes that are recognized by libexif, all
data is now stored in the MakerNote tag (as it should have been from the
very beginning).

--=20
Lutz M=FCller <lu...@us...>

Re: [Libexif-devel] Python wrapper for libexif?

[Lutz <lu...@us...>]

On Thu, 2003-10-30 at 20:06, Fred L. Drake, Jr. wrote:
> How about documentation?

Don't you like the header files? :-)

The programs in libexif/test demonstrate pretty well how to use libexif.

How would you like the documentation to be?

Regards
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Re: libmnote and libexif merged

[Roberto C. <rob...@en...>]

Lutz Müller wrote:
> 
> Hello!
> 
> I merged libmnote into libexif. Canon maker notes now should be loaded
> and saved correctly (see test/test-mnote). That is, you should no longer
> experience any data loss when using libexif on your canon EXIF data.
> 
> I have yet to make exif aware of the new functionality.
> 
> I haven't fixed the pentax and olympus maker notes yet.
> 
> Regards
> --
> Lutz Müller <lu...@us...>

Hello,
I'm very glad to receive such a good news and to see that the mailing
list is now back to normal, thanks for your work!

I haven't had yet enough time to look at it closely as I would like to,
in the meantime a couple of questions naturally come into my mind:
What happens to a picture with a maker note not recognized by libexif?
Since the format of maker notes is usually not disclosed by camera
manifacturers and not completely known, which are the assumptions
libexif currently does about it in order to prevent loss of data?

Cheers,
Roberto

[Libexif-devel] Python wrapper for libexif?

[Fred L. D. Jr. <fd...@ac...>]

Is anyone working on a Python wrapper for libexif?

How about documentation?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

[Libexif-devel] libmnote and libexif merged

[Lutz <lu...@us...>]

Hello!

I merged libmnote into libexif. Canon maker notes now should be loaded
and saved correctly (see test/test-mnote). That is, you should no longer
experience any data loss when using libexif on your canon EXIF data.

I have yet to make exif aware of the new functionality.=20

I haven't fixed the pentax and olympus maker notes yet.=20

Regards
--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Patch: maker notes no longer corrupted

[Roberto C. <rob...@en...>]

Hello,
I worked a bit on the maker note corruption problem we discussed 2 weeks
ago.
At that time we were thinking about a solution in which unused bytes of
the original exif information are mapped and then reproduced in the
output file; however I'm now convinced that it's not really necessary
and I think that a simpler solution exists.
The key idea is that entries/ifd that didn't grow in size (from the
original exif info to the modified ones) are put in the output exif at
the same offset they were in the original exif. Those that grew (or that
were missing in the original exif) are put, compacted, at the offsets
that follow the end of the exif info in the original file.
By doing so, it's sufficient to copy the full original exif info into
the new one before saving anything else to solve the problem.
As a matter of fact, this guarantees that "secret" maker notes are
copied exactly as they were and that the known exif info doesn't
overwrite them.
The price to pay is that not only compaction of exif info is no longer
done, but that its size slightly increase (I'm talking about 500 bytes'
increase in the typical worst case...).

This algorithm is straightforward to be implemented, provided that info
like the original size and offset of ifds and entry datas are marked as
soon as they are loaded.
I did it (I attach the patch) and I must say it works perfectly, at
least on the pictures produced by my Canon Powershot. I encourage
everybody with different cameras to try and report eventual problems.

A good thing to say is that I didn't modify the algorithm that saves the
exif info and that it allows both the old and new methods. What changes
is that in the new a size that corresponds to the original exif size is
immediately allocated at once and then further allocations are done only
for those elements that either grew or were missing.
The implementation is flexible and it's sufficient to set an internal
flag of ExifDataPrivate to restore the previous behaviour (try
temporarily to comment line 658 of libexif/exif-data.c and libexif will
behave as usual), which still allocates each element at a time.

Perhaps the user should be given the choice, or some heuristics that
decide from the camera name and/or the presence of libmnote whether it
is safe to compact exif information should decide in his/her stead.

Finally, the patch also includes a few minor changes. Here is a summary:
-) Addition of file libexif/exif-private.h, which contains the
   declaration of _ExifDataPrivate, _ExifContentPrivate and
   _ExifEntryPrivate structs. These data structures are internal (they
   must not be visible from libexif's interface), however several
   implementation files in the library must know about them.
-) ExifHeader is no longer duplicated in different files, however this
   also means that it is no longer static.
-) Nested switch removed in exif_data_load_data_content(...) function
   of libexif/exif-data.c

Cheers,
Roberto

Re: [Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Lutz <lu...@us...>]

On Tue, 2003-09-02 at 03:27, Ben Hartshorne wrote:
> ld: Undefined symbols:
> _libintl_bind_textdomain_codeset
> _libintl_bindtextdomain
> _libintl_dgettext

I don't know. If you can't fix the problem properly, you can always
remove manually all i18n stuff from the sources...

--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Ben H. <tr...@gr...>]

On Mon, Sep 01, 2003 at 01:54:40PM -0700, Ben Hartshorne wrote:
> On Mon, Sept. 1 at 12:05, Lutz wrote:
> >  On Mon, 2003-09-01 at 20:05, Ben Hartshorne wrote:
> >  > __USER_LABEL_PREFIX__libintl_dgettext
> >  > __USER_LABEL_PREFIX__libintl_bindtextdomain
> >  > __USER_LABEL_PREFIX__libintl_textdomain
> >  > make[2]: *** [exif] Error 1
> > =20
> >  ./configure --disable-nls

oops.  ok, this time with:

=2E/configure --disable-nls --with-popt-prefix=3D/sw

it gets as far as:
gcc -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -o exif actions.o
main.o utils.o  ../libjpeg/.libs/libjpeg.al -L/usr/local/lib -lexif -lm
-L/sw/lib -lpopt -lintl -liconv
ld: warning multiple definitions of symbol _locale_charset
/sw/lib/libintl.dylib(localcharset.lo) definition of _locale_charset
/sw/lib/libiconv.dylib(localcharset.lo) definition of _locale_charset
ld: Undefined symbols:
_libintl_bind_textdomain_codeset
_libintl_bindtextdomain
_libintl_dgettext
make[2]: *** [exif] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

-ben


--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

Re: [Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Lutz <lu...@us...>]

On Mon, 2003-09-01 at 22:54, Ben Hartshorne wrote:
> >  ./configure --without-nls

./configure --disable-nls?

--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Ben H. <tr...@gr...>]

On Mon, Sept. 1 at 12:05, Lutz wrote:
>  On Mon, 2003-09-01 at 20:05, Ben Hartshorne wrote:
>  > __USER_LABEL_PREFIX__libintl_dgettext
>  > __USER_LABEL_PREFIX__libintl_bindtextdomain
>  > __USER_LABEL_PREFIX__libintl_textdomain
>  > make[2]: *** [exif] Error 1
> =20
>  ./configure --without-nls

No change, though I actually ran
=2E/configure --with-popt-prefix=3D/sw/ --without-nls

gcc -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototy=
pes -Wnested-externs -Wpointer-arith -o exif actions.o main.o utils.o  ../l=
ibjpeg/.libs/libjpeg.al -L/usr/local/lib -lexif -lm -L/sw//lib -L/sw/lib -l=
popt -lintl -liconv ../intl/libintl.a
ld: warning multiple definitions of symbol __nl_find_msg
=2E./intl/libintl.a(dcigettext.o) definition of __nl_find_msg in section (_=
_TEXT,__text)
/sw//lib/libintl.dylib(dcigettext.lo) definition of __nl_find_msg
ld: warning multiple definitions of symbol _locale_charset
/sw//lib/libintl.dylib(localcharset.lo) definition of _locale_charset
/sw//lib/libiconv.dylib(localcharset.lo) definition of _locale_charset
ld: Undefined symbols:
__USER_LABEL_PREFIX__libintl_dgettext
__USER_LABEL_PREFIX__libintl_bindtextdomain
__USER_LABEL_PREFIX__libintl_textdomain
make[2]: *** [exif] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

-ben

--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

Re: [Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Lutz <lu...@us...>]

On Mon, 2003-09-01 at 20:05, Ben Hartshorne wrote:
> __USER_LABEL_PREFIX__libintl_dgettext
> __USER_LABEL_PREFIX__libintl_bindtextdomain
> __USER_LABEL_PREFIX__libintl_textdomain
> make[2]: *** [exif] Error 1

./configure --without-nls

--=20
Lutz M=FCller <lu...@us...>

[Libexif-devel] Re: difficulty installing exif on MacOSX - pkg-config

[Ben H. <tr...@gr...>]

On Mon, Sept. 1 at 09:42, Lutz wrote:
>  On Mon, 2003-09-01 at 07:57, Ben Hartshorne wrote:
>  > ben@ibook-laptop ~$ PKG_CONFIG_PATH=3D/usr/local/lib
> =20
>  You're new to linux, ain't you? Try=20
> =20
>  'export PKG_CONFIG_PATH=3D/usr/local/lib/pkgconfig'

no, just suffering from a case of the stupids.  ;)  i tried to think of
a rationalle why I wouldn't have to export my variable for pkg-config to
see it, but I couldn't...  ::sigh::

It's still not compiling, but this time with what seems to be a more
macosx porting issue than a shell variable scope issue.

First I had to add /sw/include/ to the -I lines so it would find popt.h

Then just about every file compiled complains that:
=2E./intl/libintl.h:129: illegal function definition, found `__asm__'
=2E./intl/libintl.h:146: illegal function definition, found `__asm__'
=2E./intl/libintl.h:166: illegal function definition, found `__asm__'
but they aren't fatal errors

Finally it dies at:
gcc -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -o exif actions.o
main.o utils.o  ../libjpeg/.libs/libjpeg.al -L/usr/local/lib -lexif -lm
=2E./intl/libintl.a
ld: Undefined symbols:
__USER_LABEL_PREFIX__libintl_dgettext
__USER_LABEL_PREFIX__libintl_bindtextdomain
__USER_LABEL_PREFIX__libintl_textdomain
_poptFreeContext
_poptGetArgs
_poptGetContext
_poptGetNextOpt
_poptHelpOptions
_poptPrintHelp
_poptSetOtherOptionHelp
make[2]: *** [exif] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

This looked like it was still having trouble finding popt.  Perhaps it
found the popt header but not the library?

I did a 'make dist-clean' and reading through configure, found
--with-popt-prefix.  I ran './configure --with-popt-prefix=3D/sw/' and it
got a little further. =20

It now fails at:
gcc -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -o exif actions.o
main.o utils.o  ../libjpeg/.libs/libjpeg.al -L/usr/local/lib -lexif -lm
-L/sw//lib -L/sw/lib -lpopt -lintl -liconv ../intl/libintl.a
ld: warning multiple definitions of symbol __nl_find_msg
=2E./intl/libintl.a(dcigettext.o) definition of __nl_find_msg in section
(__TEXT,__text)
/sw//lib/libintl.dylib(dcigettext.lo) definition of __nl_find_msg
ld: warning multiple definitions of symbol _locale_charset
/sw//lib/libintl.dylib(localcharset.lo) definition of _locale_charset
/sw//lib/libiconv.dylib(localcharset.lo) definition of _locale_charset
ld: Undefined symbols:
__USER_LABEL_PREFIX__libintl_dgettext
__USER_LABEL_PREFIX__libintl_bindtextdomain
__USER_LABEL_PREFIX__libintl_textdomain
make[2]: *** [exif] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

and I've about hit the edge of knowing what to do next. =20

Suggestions?

Thanks much,


-ben

--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net