Bugzilla Bug 146316

This seems to be true on both Linux and FreeBSD. I'm not sure while that don't
break on Linux x86 (maybe size_t there is 32-bit?), but it does break on
FreeBSD x86 at least, as sizeof(unsigned long) != sizeof(size_t), thus the old
and the new prototype are actually incompatible:

i686-gentoo-freebsd6.1-ar  r ../../libcrypto.a sha_dgst.o sha1dgst.o sha_one.o
sha1_one.o sha256.o sha512.o sx86-elf.o
i686-gentoo-freebsd6.1-ranlib ../../libcrypto.a || echo Never mind.
gmake[2]: Leaving directory
`/var/tmp/portage/openssl-0.9.8b/work/openssl-0.9.8b/crypto/sha'
making all in crypto/mdc2...
gmake[2]: Entering directory
`/var/tmp/portage/openssl-0.9.8b/work/openssl-0.9.8b/crypto/mdc2'
gmake[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
rule.
gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DL_ENDIAN -DTERMIOS -Wall -DOPENSS
L_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -O2
-march=athlon-tbird -ggdb -fno-inline -Wa,--noexecstack   -c -o mdc2dgst.o
mdc2dgst.c
mdc2dgst.c:88: error: conflicting types for 'MDC2_Update'
/usr/include/openssl/mdc2.h:87: error: previous declaration of 'MDC2_Update'
was here
distcc[79672] ERROR: compile mdc2dgst.c on farragut failed
gmake[2]: *** [mdc2dgst.o] Error 1
gmake[2]: Leaving directory
`/var/tmp/portage/openssl-0.9.8b/work/openssl-0.9.8b/crypto/mdc2'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory
`/var/tmp/portage/openssl-0.9.8b/work/openssl-0.9.8b/crypto'
gmake: *** [build_crypto] Error 1

trying to add -I. to INCLUDES seems not to work (don't appear on the command
line).

From crypto/mdc2/mdc2dgst.c:

#include <openssl/des.h>
#include <openssl/mdc2.h>


Not only it uses the installed copy, but it's likely to die if I try to build
it without OpenSSL already installed, too (not that I can try right now,
wouldn't like cutting myself out of ssh).

Created an attachment (id=96119) [edit]
openssl-0.9.8-build.patch

The problem seems to be that the ./Configure stage fails during run of "make
links" (on both my Linux and FreeBSD boxes), so it has to be ran by hand to
make sure that the links are created.

The attached patch solves the issue (and updates the config script to work for
the new FreeBSD target names).

ive committed the gentoo.config updates

Configure runs the 'links' target just fine on my linux machine

Created an attachment (id=97176) [edit]
openssl-0.9.8c-gmake.patch

the Configure perl script runs 'make depend' which 'partially' works in bsd.
As the depend target also runs the links target, the latter gets 'correctly'
run until it reaches the first subdir of the crypto/ directory (crypto/objects)
where it first fails.
After this, by running emake depend again, it doesn't see the missing 'links'
targets as the first one (crypto/) was already run.
The patch just changes 'make depend' in Configure for 'gmake depend'.

Created an attachment (id=97182) [edit]
gentoo-config.patch

This one corrects the build system for freebsd in the gentoo.config script.

why does it fail ?

(From update of attachment 97182 [edit])
merged

(In reply to comment #7)
> why does it fail ?
> 

It fails exactly like this:
http://www.nabble.com/crypt-des-dx86-out.s-fails-on-NetBSD-p202913.html

that isnt what i meant

why does the current make system not run the links targets properly

Created an attachment (id=111431) [edit]
Don't set TOP when making links

Further analysis shows that something in the chain is clobbering TOP. As to
where or why I still don't know, but it ONLY gets clobbered when make is called
from the ebuild - on the command line it works just fine.

This patch stops TOP being set on the links target.

maybe something specific to BSD ?  going by Diego's comment #1, doing:

# rm -rf /usr/include/openssl
# emerge openssl

works for me in Linux with 0.9.8e ...

If so I have no idea where.
swapping /bin/sh to be bash and using gmake still results in a failure to make
the links target when used in portage. Even if we rm /usr/include/openssl, the
links target fails to build because it once it goes down a directory it cannot
use $TOP correctly in the Makefile for whatever reason.

This line is the one in question though
$(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target
Just the act of removing TOP makes it work - and this is ONLY necessary inside
portage environment.

sed -i -e 's/TOP=\.\.//g' Makefile.org

Adding that to src_unpack fixes things for us quite nicely.

Or, just unset MAKE
Portage - or something - is setting MAKE to gmake and this is the root cause.

So either
1) we unset MAKE in the openssl ebuild before Configure
2) Stop portage from forcing MAKE env var on ebuilds

Why does portage export MAKE anyway? Don't we have configure autotool foo for
that anyway?

(In reply to comment #15)
> Or, just unset MAKE
> Portage - or something - is setting MAKE to gmake and this is the root cause.

Turns out it's the FreeBSD profile that's setting it :/
Let's see if we can punt that now

i'm 99% sure you cant punt that ... the default `make` invokes the BSD make
which does not support GNU extensions which is what many packages require

dostrow hooked me up with a shell account on a bsd box so i can actually
research this now :P

Yeah, I realise that :P

One solution I'm currently working on is this getting emake to default to
gmake, if gmake is available otherwise make.

i really dont think that's the solution either

what may work though is something like:
exec env -uMAKE ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@"

otherwise i'll dig through the build system and see why MAKE isnt properly
being incremented when MAKE is set in the env

it seems to stem from the fact that the links target is executed by the perl
Configure script and it starts off by executing `make`, not $MAKE, and
certainly not `emake`

you can reproduce this by unpacking the openssl tarball on a BSD box, exporting
MAKE to gmake, and then running the Configure script followed by `make links`

doing `gmake links` or `$MAKE links` works just peachy

so the correct fix here is to change the Configure perl script to execute
`$ENV{'MAKE'}` rather than `make` by default ... ive added this to
openssl-0.9.8e-r3, so re-open the bug if that version does not work for you