Am 19.12.2011, 05:30 Uhr, schrieb Chad J <chadjoan@__spam.is.bad__gmail.com>:

On 12/18/2011 05:36 PM, Marco Leise wrote:
Am 18.12.2011, 20:58 Uhr, schrieb mta`chrono
<[email protected]>:

Your problem seems to be really frustrating. I'm using ubuntu amd64 and
everything is fine here.

I'd like to reproduce your issue. Can you paste a link to your gentoo
installation iso file. I'll setup a VM here.

Did you install dmd,druntime,phobos from sources or some kind of
packages/repo?

Uhm, Gentoo is a source distribution. The outcome of a package
installation can depend on many things, such as used compiler,
enabled/disabled features for the package and compiler/linker flags.
That said, I am currently maintaining this ebuild (package
information/installation file):
http://gentoo-overlays.zugaina.org/sunrise/portage/dev-lang/dmd/dmd-2.056.ebuild
It is a continuation of the abandoned "d-overlay" ebuild and the
dmd.conf generation code originates from there. On a positive note,
Ubuntu recently had a problem with dmd when they switched to
--as-needed, that does not occur with the Gentoo ebuild, since
--as-needed was already in use there for a while.
Since I am not an expert with Gentoo ebuilds or executable linking, I
did not change the ebuild much and it works for me. The stack traces are
in deed the reason for --export-dynamic. If there is anything that
should be resolved in dmd.conf for Gentoo, instead of the compiler
itself, then I am the one to bug.

Installation goes like this (assuming layman has been installed):

1. Add official external repository for wannabe packages:
layman -a sunrise

2. Install latest dmd (needs to be unmasked in
/etc/portage/package.keywords first):
emerge dmd

Cool!

I should probably mention this in-thread:
This is a problem with /hardened/ Gentoo.  This will only happen if you
build GCC with the hardened USE flag.

If you want to solve this at an ebuild level, I would suggest adding the
hardened USE flag to the package and making that apply a patch that
removes the --export-dynamic from dmd.conf.  How exactly you would do
this, I'm not sure, because I am not an ebuild maintainer, but I am
pretty sure it can be done.  I'm not sure if it's worth it though if
others manage to fix DMD's PIC generation within, say, next release.

It sounds like it would be a hack because then stack tracing would still
not work on hardened systems.  But at least things would compile.

Either way, thank you for your efforts!

Ok, then I'll remember this problem for the next version. I always have a bad feeling writing hacks when I don't understand the problem. Btw, there is also someone working on an ebuild for D1, that can be installed in parallel. I don't know if he's active in this news group.

Reply via email to