| Summary: | dev-libs/openssl-0.9.8b uses installed headers to build | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | FreeBSD | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bsd+disabled, jakub |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | FreeBSD | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 176058 | ||
| Attachments: |
openssl-0.9.8-build.patch
openssl-0.9.8c-gmake.patch gentoo-config.patch Don't set TOP when making links |
||
|
Description
Diego Elio Pettenò (RETIRED)
2006-09-04 14:32:58 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). Created attachment 96119 [details, diff]
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 attachment 97176 [details, diff]
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 attachment 97182 [details, diff]
gentoo-config.patch
This one corrects the build system for freebsd in the gentoo.config script.
why does it fail ? Comment on attachment 97182 [details, diff]
gentoo-config.patch
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 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.
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
|