www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd.conf's -L--export-dynamic prevents my compiler from working

reply 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!)
Dec 18 2011
next sibling parent reply 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!)

Dec 18 2011
parent 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.
Dec 18 2011
prev sibling next sibling parent reply "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
Dec 18 2011
parent reply 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?
Dec 18 2011
parent 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!
Dec 18 2011
prev sibling next sibling parent "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
Dec 18 2011
prev sibling next sibling parent "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.
Dec 18 2011
prev sibling parent "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.
Dec 20 2011