not getting PIC for shared library

[John-Colvin]

on ubuntu 15.04 x86_64

A simple 1-file project with "targetType": "dynamicLibrary" doesn't get compiled with -fPIC

The compile step, as reported by dub -v build is
dmd -c -of.dub/build/library-debug-linux.posix-x86_64-dmd_2067-FA32B08D9C0006B2A066E7CC872D6501/ppyd.o -debug -g -w -version=Have_ppyd ppyd.d

[John-Colvin]

I notice this has been reported and fixed once before. Is it in the test suite?

[John-Colvin]

tested with dub 0.9.23 and git HEAD

[p0nce]

Hitting this too.

[s-ludwig]

Okay, sneaked the fix in before release ;) Would be good if someone could test if this also fixes more complex scenarios, I just tested building a dynamicLibrary package directly, but not as a dependency for example.

[p0nce]

I think this isn't fixed indeed.

I have a non-trivial scenario here: https://github.com/p0nce/dplug/blob/master/examples/distort/dub.json

In non-combined here is the dub -v -f output: http://pastebin.com/BRgv7NXH
It does compile in --combined.

System: DUB master, DMD 2.067.1, Ubuntu

My understanding is that -fPIC is a code generation flag that should be applied to anything that goes in a shared library. In the DUB log, static libraries dependencies are not compiled with -fPIC which I believe is the problem. No problem in combined since everything get to be compiled with -fPIC.

[s-ludwig]

Ah, right, didn't think of that. This will require some deeper changes, because the static library files will have to get a different hash value in the build cache folder. It will probably also mean that if the same static library is used for both, a dynamic library and an executable, the PIC version will also be used for the executable, even if that isn't ideal. I don't think it will be possible to map that to other build systems otherwise.

[p0nce]

Unfortunately because of DMD codegen bugs, I tend to rely on sub-packages with {optimization | inlining} disabled so --combined is less than ideal (though maybe 2.068-b2 brings an end to this(EDIT: no, it does not)).

It will probably also mean that if the same static library is used for both, a dynamic library and an executable, the PIC version will also be used for the executable, even if that isn't ideal.

Sorry I don't understand this sentence, does this happen even if such builds get different hash values?

.

[s-ludwig]

It will probably also mean that if the same static library is used for both, a dynamic library and an executable, the PIC version will also be used for the executable, even if that isn't ideal.

Sorry I don't understand this sentence, does this happen even if such builds get different hash values?

The problem is that each package corresponds (at most) to a single binary target during a single build. Think of a VisualStudio solution where you'd just be able to insert each project once and would have to decide for each if it should be built with or without -fPIC. So if the same static library package is referenced both by a dynamic library and an executable within the same dependency graph, it will be necessary to generally enable -fPIC for it.

Now it would be possible to work around that, especially within DUB's own builder, but I'm not sure how good that idea would generally be.

[p0nce]

OK I see. I found it strange because in my DUB use cases only the top-level project is possibly an executable or a shared library, everything else is a source library.

[wilzbach]

-fPIC has been DMD's default since 2.072 for 64-bit builds.
@p0nce is this still an issue for you?

[John-Colvin]

I'm pretty sure the bug this was re-opened for was resolved here

[wilzbach]

Cool. Closing then. @p0nce feel free to reopen if this is incorrect

[p0nce]

@wilzbach , definately no problem here :)