Since 0.16.0, can't build any project with DUB whenever it has a dependency

[p0nce]

This seriously limits the ability to find more bugs since none of my projects build.

For an example, try to build d-idioms:

$ dub --compiler=ldc2
Fetching dmarkdown 0.1.0 (getting selected version)...
Placing dmarkdown 0.1.0 to /Users/ponce/.dub/packages/...
Performing "debug" build using ldc2 for x86_64.
Building dmarkdown 0.1.0 configuration "library"...
Error: failed to create path to file: .dub/obj/../../.dub/packages/dmarkdown-0.1.0/.dub/build/library-debug-posix.osx-x86_64-ldc_0-9D24AF7ACC3A312273AFCBB86B148109/libdmarkdown.a
No such file or directory
ldc2 failed with exit code 1.

What changed? It used to work with 0.15.x

(BTW I maintain the DUB PR that allows to use --compiler=ldc2 on Mac: dlang/dub#638
It would be merged more easily if LDC accepted multiple -march flags like DMD (yes, DUB sends many -march flags for some reason)).

OS: Mac OS X

[p0nce]

Same problem on Windows.

Maybe the problem is the discrepancy between output files:

ldc2 -march=x86-64 -lib -of..\..\..\AppData\Roaming\dub\packages\gfm-3.0.3\.dub\
build\library-debug-windows-x86_64-ldc_0-CC1AE8AC3A572E41539A953C6EC83851\libgfm
_core.a -d-debug -g -w -oq -od=.dub/obj -d-version=Have_gfm_core -I..\..\..\AppD
ata\Roaming\dub\packages\gfm-3.0.3\core ..\..\..\AppData\Roaming\dub\packages\gf
m-3.0.3\core\gfm\core\memory.d ..\..\..\AppData\Roaming\dub\packages\gfm-3.0.3\c
ore\gfm\core\package.d ..\..\..\AppData\Roaming\dub\packages\gfm-3.0.3\core\gfm\
core\queue.d
Error: failed to create path to file: .dub/obj\..\..\..\AppData\Roaming\dub\pack
ages\gfm-3.0.3\.dub\build\library-debug-windows-x86_64-ldc_0-CC1AE8AC3A572E41539
A953C6EC83851\libgfm_core.a.lib
no such file or directory

[schuetzm]

I can confirm this. The difference to previous versions is that for libraries, -of filenames are now relative to the directory provided by -od, while in previous versions they were relative to the current directory. If this is an intentional change, maybe dub has to be updated?

[dnadlinger]

It is not an intentional change. We should match DMD's behavior here. Anybody care to submit a PR?

[redstar]

Fixed in merge-2.067 branch.

[schuetzm]

Something is not quite right yet (0.160.0 alpha3). When compiling current vibe.d with dub test --compiler=ldc2 -v, LDC complains:

Error: failed to create path to file: .dub/obj/../../.dub/packages/memutils-0.4.1/.dub/build/secure-unittest-linux.posix-x86_64-ldc_0-38ACFEB5A4C0EFEDC50803AF380B9A85/libmemutils.a

The build command-line starts with (only possibly relevant args):

ldc2 -lib -of../../.dub/packages/memutils-0.4.1/.dub/build/secure-unittest-linux.posix-x86_64-ldc_0-38ACFEB5A4C0EFEDC50803AF380B9A85/libmemutils.a -oq -od=.dub/obj ...

I believe this file is supposed to end up in ../../.dub/packages/memutils-0.4.1/... relative to the current directory; at least this is where DUB tries to look for it later. So it looks like nothing has changed.

[schuetzm]

This file (which is linked from the release page) doesn't contain the change:
https://github.com/ldc-developers/ldc/releases/download/v0.16.0-alpha3/ldc-0.16.0-alpha3-src.tar.gz

driver/linker.cpp:456 is not commented out.

[dnadlinger]

@redstar: Ping. What happened here? This is pretty critical.

[redstar]

I am checking it...

[testing-in-chrome]

Please reopen this! I can't compile a Gtk-D based project using LDC, even though it compiles happily with DMD:

$ dub run --build=release --compiler=ldc2 --parallel
Performing "release" build using ldc2 for x86_64.
gtk-d:gtkd 3.6.6: building configuration "library"...
Error: failed to create path to file: .dub/obj/../../../.dub/packages/gtk-d-3.6.6/gtk-d/.dub/build/library-release-linux.posix-x86_64-ldc_2071-67135794B6626DACADC0654E95656376/libgtkd-3.a
No such file or directory
ldc2 failed with exit code 1

[dnadlinger]

@testing-in-chrome: Please open a new issue with all the relevant details (operating system/compiler/dub versions, etc.). This has been closed for almost two years, and if you are using the latest version of LDC, you are likely seeing a different issue.

[PetarKirov]

I believe that this was something fixed quite a while ago (I think it was around 1.1.0). As a matter of fact, I was not able to reproduce your error with dub 1.4.0 and ldc 1.3.0.