Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 146316 - dev-libs/openssl-0.9.8b uses installed headers to build
Summary: dev-libs/openssl-0.9.8b uses installed headers to build
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: FreeBSD (show other bugs)
Hardware: All FreeBSD
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Blocks: 176058
  Show dependency tree
Reported: 2006-09-04 14:32 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2007-09-30 12:08 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

openssl-0.9.8-build.patch (openssl-0.9.8-build.patch,2.39 KB, patch)
2006-09-05 15:24 UTC, Diego Elio Pettenò (RETIRED)
Details | Diff
openssl-0.9.8c-gmake.patch (openssl-0.9.8c-gmake.patch,401 bytes, patch)
2006-09-16 13:30 UTC, Javier Villavicencio (RETIRED)
Details | Diff
gentoo-config.patch (gentoo-config.patch,732 bytes, patch)
2006-09-16 14:25 UTC, Javier Villavicencio (RETIRED)
Details | Diff
Don't set TOP when making links (x,573 bytes, patch)
2007-02-27 16:11 UTC, Roy Marples (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2006-09-04 14:32:58 UTC
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.
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).
Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-09-04 14:41:45 UTC
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).
Comment 2 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-09-05 15:24:35 UTC
Created attachment 96119 [details, diff]

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).
Comment 3 SpanKY gentoo-dev 2006-09-05 22:02:05 UTC
ive committed the gentoo.config updates
Comment 4 SpanKY gentoo-dev 2006-09-05 22:11:34 UTC
Configure runs the 'links' target just fine on my linux machine
Comment 5 Javier Villavicencio (RETIRED) gentoo-dev 2006-09-16 13:30:03 UTC
Created attachment 97176 [details, diff]

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'.
Comment 6 Javier Villavicencio (RETIRED) gentoo-dev 2006-09-16 14:25:12 UTC
Created attachment 97182 [details, diff]

This one corrects the build system for freebsd in the gentoo.config script.
Comment 7 SpanKY gentoo-dev 2006-09-16 23:34:26 UTC
why does it fail ?
Comment 8 SpanKY gentoo-dev 2006-09-16 23:35:06 UTC
Comment on attachment 97182 [details, diff]

Comment 9 Javier Villavicencio (RETIRED) gentoo-dev 2006-09-17 03:42:48 UTC
(In reply to comment #7)
> why does it fail ?

It fails exactly like this:
Comment 10 SpanKY gentoo-dev 2006-09-17 23:22:25 UTC
that isnt what i meant

why does the current make system not run the links targets properly
Comment 11 Roy Marples (RETIRED) gentoo-dev 2007-02-27 16:11:25 UTC
Created attachment 111431 [details, diff]
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.
Comment 12 SpanKY gentoo-dev 2007-06-22 02:38:09 UTC
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 ...
Comment 13 Roy Marples (RETIRED) gentoo-dev 2007-08-08 13:22:50 UTC
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.
Comment 14 Roy Marples (RETIRED) gentoo-dev 2007-08-08 13:57:00 UTC
sed -i -e 's/TOP=\.\.//g'

Adding that to src_unpack fixes things for us quite nicely.
Comment 15 Roy Marples (RETIRED) gentoo-dev 2007-08-08 15:55:54 UTC
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?
Comment 16 Roy Marples (RETIRED) gentoo-dev 2007-08-08 16:07:23 UTC
(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
Comment 17 SpanKY gentoo-dev 2007-08-08 23:47:42 UTC
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
Comment 18 Roy Marples (RETIRED) gentoo-dev 2007-08-09 06:40:43 UTC
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.
Comment 19 SpanKY gentoo-dev 2007-08-10 04:30:09 UTC
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
Comment 20 SpanKY gentoo-dev 2007-09-30 12:08:55 UTC
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