• Chad J (15/15) Dec 18 2011 Speaking of issues that will frustrate newcomers... having dmd generate
• Sean Kelly (5/25) Dec 18 2011 It's needed to generate stack traces on Linux. Weird that it creates bro...
• Chad J (7/9) Dec 18 2011 Good to know!
• Martin Nowak (13/29) Dec 18 2011 Apparently you build shared executables with you gentoo setup.
• mta`chrono (6/6) Dec 18 2011 Your problem seems to be really frustrating. I'm using ubuntu amd64 and
• Marco Leise (24/30) Dec 18 2011 Uhm, Gentoo is a source distribution. The outcome of a package
• Chad J (14/51) Dec 18 2011 Cool!
• Marco Leise (6/57) Dec 18 2011 Ok, then I'll remember this problem for the next version. I always have ...
• Marco Leise (5/69) Dec 20 2011 hasufell, who is working on a D1 ebuild just hit that problem (active

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Speaking of issues that will frustrate newcomers... having dmd generate
executables that segfault would be particularly /bad/.

I refer to my post 19 on this bug:
http://d.puremagic.com/issues/show_bug.cgi?id=5278
(which is the most recent as of this writing.)

Stock DMD hasn't worked on my system for... let's see... a little over a
year now.

I just can't compile things with D unless I go through some strange
contortions.

The problem was introduced when -L--export-dynamic was placed in dmd.conf.

Unless there is an important reason for -L--export-dynamic to be there,
could we please remove it?  It makes my (usually awesome) D experience,
uh, suck!
(From my perspective it was unceremoniously added and then made my
compiler just spontaneously not work at all anymore.  Bad bad bad!)

Sean Kelly <sean invisibleduck.org> writes:

It's needed to generate stack traces on Linux. Weird that it creates broken a=
pps for you.=20

Sent from my iPhone

On Dec 18, 2011, at 7:54 AM, Chad J <chadjoan __spam.is.bad__gmail.com> wrot=
e:

 Speaking of issues that will frustrate newcomers... having dmd generate
 executables that segfault would be particularly /bad/.
=20
 I refer to my post 19 on this bug:
 http://d.puremagic.com/issues/show_bug.cgi?id=3D5278
 (which is the most recent as of this writing.)
=20
 Stock DMD hasn't worked on my system for... let's see... a little over a
 year now.
=20
 I just can't compile things with D unless I go through some strange
 contortions.
=20
 The problem was introduced when -L--export-dynamic was placed in dmd.conf.=

=20
 Unless there is an important reason for -L--export-dynamic to be there,
 could we please remove it?  It makes my (usually awesome) D experience,
 uh, suck!
 (=46rom my perspective it was unceremoniously added and then made my
 compiler just spontaneously not work at all anymore.  Bad bad bad!)

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

On 12/18/2011 01:28 PM, Sean Kelly wrote:
 It's needed to generate stack traces on Linux. Weird that it creates broken
apps for you. 
 

Good to know!

Thanks for the info.

I really love the idea of working stack traces.  I'm glad there is
effort on this front.  I think that stack traces are a huge missing
piece for D to be highly productive, as they make a large class of
runtime bugs relatively easy to figure out.  Having them is very important.

"Martin Nowak" <dawg dawgfoto.de> writes:

On Sun, 18 Dec 2011 16:54:39 +0100, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Speaking of issues that will frustrate newcomers... having dmd generate
 executables that segfault would be particularly /bad/.

 I refer to my post 19 on this bug:
 http://d.puremagic.com/issues/show_bug.cgi?id=5278
 (which is the most recent as of this writing.)

 Stock DMD hasn't worked on my system for... let's see... a little over a
 year now.

 I just can't compile things with D unless I go through some strange
 contortions.

 The problem was introduced when -L--export-dynamic was placed in  
 dmd.conf.

 Unless there is an important reason for -L--export-dynamic to be there,
 could we please remove it?  It makes my (usually awesome) D experience,
 uh, suck!
 (From my perspective it was unceremoniously added and then made my
 compiler just spontaneously not work at all anymore.  Bad bad bad!)

Apparently you build shared executables with you gentoo setup.
I'd guess that you need to compile your dmd executables with -fPIC for
this to work properly.
There are some relocation bugs with dmd's PIC code though. I'm working on  
shared library
support for Elf, so most of them are fixed here  
https://github.com/dawgfoto/dmd/commits/SharedElf.

Not sure why you can sometimes compile working programs but maybe  
--export-dynamic
triggers shared executables.

http://www.gentoo.org/proj/en/hardened/pie-ssp.xml

mta`chrono <chrono mta-international.net> writes:

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?

"Marco Leise" <Marco.Leise gmx.de> writes:

Am 18.12.2011, 20:58 Uhr, schrieb mta`chrono  
<chrono mta-international.net>:

 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/
md/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

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

On 12/18/2011 05:36 PM, Marco Leise wrote:
 Am 18.12.2011, 20:58 Uhr, schrieb mta`chrono
 <chrono mta-international.net>:
 
 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!

"Marco Leise" <Marco.Leise gmx.de> writes:

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
 <chrono mta-international.net>:

 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.

"Marco Leise" <Marco.Leise gmx.de> writes:

Am 19.12.2011, 07:38 Uhr, schrieb Marco Leise <Marco.Leise gmx.de>:

 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
 <chrono mta-international.net>:

 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.

hasufell, who is working on a D1 ebuild just hit that problem (active  
hardened use-flag on Gentoo) with the compilation of dmd itself. He is at  
the time of writing looking into the Makefile to see if the  
-L--export-dynamic flag is in use there.