Here you go. Just let me know if you need anything else.

Can you please send me the file config.log by private mail (wk@gnupg.org).

Thanks for the quick response. I'm using version 1.4.0 and the only
modification I made was to cipher/random.h. I added #include
"gpg-errors.h" to get rid of an error I was receiving concerning
gpg_error_t. Other than that, to configure I just took the defaults by
running ./configure. Everything appeared to compile and install without
error. However, when running make check I see the following:

I just added #include "gpg-error.h" to random.h and all compiled OK.

I'm pretty sure I have it installed correctly. There's really not that much to
it. All of the gpg-error files are in /usr/local and I do see the gpg-error.h
file with the typedef for gpg_error_t. Is it possible that there is a problem
with gcc-3.1?

Did you install libgpg-error properly? The type gpg_error_t is defined in
gpg-error.h and included by gcrypt.h.

I made the following changes in random.h that at least allowed the program to
finish making:

Given that libgcrypt builds fine on non-GNU platforms, I suggest to take this to
the GNU gold developers.

Thanks; I tried that with exactly the same result.

use

Fixed in my working copy. Thanks.

Okay, fixed in the trunk (r1276). Thanks.

You are obviously right.

Implemented in Libgcrypt trunk.

Partly done in 1.3. This will be improved over time. Using the visibility
attribute has higher priority, though.

I have commited a similar fix to the SVN (-r1214).

Moved to libgcrypt until we have implemented this feature.

Scheduled for 1.3

Fixed in 1.2.6 (to be released today) and in the trunk's SVN.

Fixed in in version 1.5. Released today.

Checking the current libgcrypt11 package from Sid, shows that tuis pathc is not
anymore used. Thus I cose this bug.

I think I addressed this with revision 1180. It is easy to add more fallback
types, although I stuck to socklen_t only for now. I will check if I can reach
some of the original submitters for testing.

I think it is sufficient to do it for trunk (1.3).

Yeah, I agree that we need to generate it with configure.

Marcus, any opinion on this?

Duplicate of T236

Resolved a long time ago.

We switched the thread support model in the meantime. You should not have this
problem anymore.

Fixed. Thanks.

Fixed in 1.2.1, releases earlier.

D18: 44_hppa.revert.patch

Your patch is gcc specific. I developed a more C standard one. Please check it out.

Fixed in CVS.

D16: 43_newrijndael.diff

D17: 42_rijandel.diff

fixed in current versions.

No feedback received - assume that it is okay

No feedback - must have worked

Solved by removing the double test and directly using the
numerical oeprator -ge

taken