Re: [GNUnet-developers] libextractor, macos x

[Christian Grothoff]

On Sunday 14 March 2004 11:56, Jussi Eloranta wrote:
> Hi,
>
> Couple of things I ran into with gnunet 0.6.1c:
>
> 1.
>
> On GNU/Linux (Fedora) I get:
>
> Resolving symbol 'libextractor_lower_extract' in library
> libextractor_lower failed, so I tried '_libextractor_lower_extract',
> but that failed also.  Errors are: /usr/lib/libltdl.so.3: undefined
> symbol: libextractor_lower_extract; and then: /usr/lib/libltdl.so.3:
> undefined symbol: _libextractor_lower_extract
> Inserting test.dat (no description supplied, unknown) under keyword
> test.dat.
>
> My guess is that the function name in libextractor (0.2.6) file
> .../plugins/lowerextractor.c has wrong function name:
>
> extract() should be libextractor_lower_extract() ? Or was this
> generated somehow automagically and this just did something
> wrong?

You are correct, and that bug was fixed in the libextractor CVS a while ago, 
but nevertheless after the last release.

> 2. On MacOS X (10.3.2 with gcc-3.3 from apple) the existing config stuf
> for extractor 0.2.6 did not
> work for me. I had to modify the configure.ac file as follows:
>
> case "$host_os" in
> darwin*)
> #    AM_CONDITIONAL(DARWIN_LIBTOOL_BROKEN,true)
> #    AC_DEFINE([USE_NS_MODULE],1,[Determines if we should use the
> NSModule API for dynamic loading])
>      AM_CONDITIONAL(DARWIN_LIBTOOL_BROKEN,false)
>      LIBLTDL=/sw/lib/libltdl.a
>      LTDLINCL=-I/sw/include
>      ;;
>
> [This requires libtool stuff installed under /sw, which is the default
> if one is
> using Fink] Also maybe one should add a switch to configure which would
> allow
> specification of libltdtl?

I'm not sure if hardwireing /sw is a good thing.  I'm not familiar with OSX, 
so I've cc'ed this to Filip Pizlo who did the OSX port.  I'd suggest you 
discuss the matter with him to find out what is the correct approach.

> 3. dictionary-builder.c in ... plugins/printable
>
> dumps core. This seems to be due to the following line (isol. within
> !!!s):
>
>    while (1 == fscanf(dictin, "%s", (char*)&line)) {
>      words[cnt] = strdup(line);
>
> !!!
>      if (words[cnt][strlen(words[cnt]-1)] != '%')
> !!!
>
>        cnt++;
>
> There were no % characters in the *.txt files so I just commented
> the above line. Is the idea that % is a comment sign ?
>
> BTW configure sets up the compilation for gcc-3.3 (from Apple).

It used to be a comment sign, but the line is historic and should go away 
(fixed in CVS). Oh, and the bug is that it should have been 
"strlen(words[cnt])-1".

> 4. On MacOS X there is no values.h header (which is btw obsolete anyway)
>
> I believe that this should be replaced with limits.h and float.h
> and correct symbols should be used? (well, it compiles with these two)
>
> This reference occurs in
> GNUnet-0.6.1c/src/applications/afs/module/manager.c

Fixed in CVS.

> I used the following configure line:
>
> /configure --with-extractor=/usr/local --with-gdbm=/sw
>
> (gdbm was installed from Fink) Also I believe that the compilation
> found libltdl from /sw (FInk again).
>
> 5. Weird dynamic linker problem on Macos X. It insisted that _gettext
> could not be found when I start gnunetd. If force it to look for
> libintl.dylib
> then it works, ie.:
>
> setenv DYLD_INSERT_LIBRARIES /sw/lib/libintl.dylib
> /usr/local/bin/gnunetd
>
> It appears to be a problem for all gnunet-* binaries (so a quick hack
> is to put the setenv in .cshrc or whateverRC).
>
> This is probably a problem on my machine... but who knows...

GNUnet has not yet been ported to OSX and the dynamic loading of libraries 
with libtool is the known problem with OSX (see file "PLATFORMS").

> 6. Files download correctly but at the end of download (and
> occasionally during download) I get:
>
> [comp56:~/gnunet-downloads] % gnunet-gtk
> Mar  7 21:52:18 FAILURE: file corrupted (or bug), top crc mismatch in
> block 1 0: 7d9f6b4d != 25812b15 or 466dc92 != 466dc92
> Mar  7 21:52:18 __BREAK__ at block.c:1825
> Mar  7 21:52:18 top CRC mismatch!
> Mar  7 21:52:18 __BREAK__ at logging.c:240
>
> It calims CRC error but, in fact, there is no error in the downloaded
> file.

Whew.  Now that's something really new. Must have been two years since I saw 
something like that.  Either you managed to download a file that was inserted 
with a broken version of freeway (always possible) or there's a really odd 
problem with your platform or there's a really, really rare bug.  Let me 
quickly describe what this error is.  The CRC that is part of the GNUnet URI 
is, strictly speaking, redundant.  For the download, only the two hashcodes 
and the size are required.  Anyway, to ensure that everything is really, 
really ok, GNUnet checks the CRC at the end (which is, btw, *not* the 
ordinary crc32 of the entire file).  If the URI that you type has the wrong 
CRC, you should see this message.  Now, a malicious party can clearly 
generate search results that download fine but where that CRC (or any of the 
other CRCs, there's more than just this one) is wrong.  And just like a 
malicious party, a broken implementation could also cause this.

If you downloaded a file that you inserted yourself, please see if you can 
reproduce it and if so, consider making the file available to us for testing. 
If the file came from elsewhere, it is possible that nothing is wrong and 
that it's just freeway (Stephane had reported that the first version produced 
invalid encodings).  Anyway, if you inserted the file and are able to 
reproduce the problem, I'd ask you to file a full bugreport on mantis (you 
can attach the file there), including details about your system 
configuration.  That would definitely help to track down this problem.

Christian