when compiling libgcrypt-1.2.0: In file included from ../src/g10lib.h:36, from serpent.c:28: ../src/gcrypt.h:174: warning: 'struct timeval' declared inside parameter list ../src/gcrypt.h:174: warning: its scope is only this definition or declaration, which is probably not what you want serpent.c: In function 'serpent_setkey': serpent.c:690: error: invalid storage class for function 'serpent_test' serpent.c:692: warning: implicit declaration of function 'serpent_test' serpent.c:692: warning: assignment makes pointer from integer without a cast serpent.c: At top level: serpent.c:869: error: conflicting types for 'serpent_test' serpent.c:692: error: previous implicit declaration of 'serpent_test' was here make[2]: *** [serpent.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -O3 -pipe -Wall -c twofish.c -o twofish.o >/dev/null 2>&1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Reproducible: Always Steps to Reproduce: 1. emerge libgcrypt on OSX 10.4 2. 3. Actual Results: compilation fails Expected Results: compile and install
update: libgcrypt-1.2.1 compiles and installs fine
In this case, we're long overdue for stabling version 1.2.1 anyways. (That is provided this version was bug-free for 30 days.) If we weren't overdue for stabling it, my judgement would be as follows: If there is an older stable keyworded version, drop the keyword for 1.2.0 to testing and attempt to fix it. If there wasn't an older stable keyworded version, I would stable version 1.2.1 even if it hadn't been 30 days, provided there were no open bugs with that version. If there were open bugs for version 1.2.1 and they weren't user-error type bugs, I would be forced to drop the stable keyword for version 1.2.0 -- something that can get very messy with dependencies. This is a last resort type of situation. I'm not sure if this is exactly policy. I am not aware of any Gentoo-wide policy on this. I don't like to drop stable support for a package because it causes a wide variety of problems on the user side, especially when we start dropping stable support for reverse dependencies. Anyways, I'm committing this right now.
thanks for the explanation!
