Re: [libextractor] libextractor-0.5.17 (win32) - extract.exe stops with error msg

[Nils Durner]

Hi,

> libextractor-0.5.18.zip ... works fine now :-)
Great :-)

>> > as it has been a kind of nightmare for me using
>> > cygwin
>> Right, Cygwin does not work. Use MinGW instead.
> afaik, you mean with mingw in this case "MSYS" tool from mingw.
Both, yes. Note that this is a just a build tool, it does not depend on
it on runtime.

> I can use that tool of course, but only to preprocess the code somehow
> to prepair it for vendor import, so that it can be build with our
> RosBE build tools.
Sounds reasonable then.

Depending on your setup, "preprocessing" is done using
    CFLAGS="-O2 -march=pentium -fomit-frame-pointer -s" ./configure
--prefix= --with-qt=/c/Qt/4.2.3
(this is how I build official binaries)

> The "configure" step is only reasonable for unix environments,
Not at all. Among other things, configure checks for required and
optional dependencies. This is important since you want to leave some
components out (GTK).
GNU autoconf exists for a reason. ;-)

> in
> win32 it has to be done using either msys or cygwin which means the
> vendor import each time will get complicated.
No, just paste the ./configure command above and give it a try.

> It would help to have
> the static files, that configure would generate.
Because LE has a lot of optional dependencies, this is not an option.
The result would effectively be a cut down version of LE which is not
general in any way, but specifically built to suit *your* requirements.

> Maybe it's a one-time thing, run the configure script once with msys
> and then reuse it everytime.
As soon as a source file is added, this won't work anymore.
This may also apply to extenensions to configure.ac.

> http://www.gnunet.org/hacking_win32_build.php3?xlang=English ...
> mentions libextractor depend on GTK, what exactly relies on GTK ?
The thumbnail extractor. There are two versions: the GTK based extractor
and the Qt based extractor.
This is one of the optional dependencies.
Obviously, I won't release a general "preprocessed" libextractor source
distribution with the thumbnail extractor configured out.

> Is it the core wrapper lib, or is it 'just' an optional lib, e.g. for
> ogg-format, etc. ?
Yes, the core just loads the other plugins and doesn't fail if one
plugin is missing.

> Where exactly is "GNU Gettext" and "GNU iconv" used in libextractor?
i18n & l18n:

    * localized messages & descriptions, e.g. "Brennweite" for EXIF data
    * All output strings are converted to UTF-8


> If I could avoid both, it would help a lot.
It should be easy to do but is not recommended.

> As all such unix libs are
> absolutely not common in win32 world, and would be redundant as
> Win32API provides such or similar functions already for no costs.
It's not that simple, unfortunately.

> I will try to build libextractor this weekend using msys and all
> things listed on hacking_win32_build.php3 except "GNU MP", "SQLite",
> "MySQL" and "Glade", as the following mailing list page told me:
> http://lists.gnu.org/archive/html/libextractor/2006-07/msg00011.html
Of course.

> ** SQLite for example provides a download package where all of the
> preprocessing and automatic code generation has already been done on
> these C code files, so they can be converted to object code directly
> with any ordinary C compiler.
This is fine for projects with no (or little) external dependencies. And
you still need a "make" ;-)


Just in case you don't have a solution to "DLL hell" in ReactOS: if
libextractor for ReactOS has different properties (no UTF-8 conversion)
and lacks several features (no thumbnails, no OGG, ...), it might be a
good idea to rename the library to avoid confusion (and the need for
another autoconf check ;-).

Of course, a patch to convert.c that makes LE use Win32 functions if
iconv is not available would be appreciated! :-)


Best,

Nils Durner