[BUG] Library won't compile with debug flag when referenced by another project's cabal.project file.

[noahmartinwilliams]

Description
When I set up a separate project that uses the attached cabal.project file it complains about being unable to create symbolic links.

Steps to reproduce
If I recall correctly I ran commands that were similar to:

stack new accelerate-test
cd accelerate-test
cp location-of-cabal.project .
cp location-of-cabal.project.local .
cp location-of-tester.cabal .
cp location-of-accelerate-test.cabal .
cp location-of-main.hs tester/

cabal build tester -j 

with the files:
[cabal.project.local.txt](https://github.co
tester.cabal.txt
cabal.project.txt
Main.hs.txt
accelerate-test.cabal.txt

(Note: I had to add the .txt extension to them to get github to attach these files).

Expected behaviour
The library should have been built with debugging enabled.

Your environment
OS: Arch Linux (up to date as of Sunday, October 8th 2023).
GHC version: 9.2.8
cabal version 3.6.2.0
both installed via ghcup version 0.1.19.0
stack version: 2.11.1
accelerate version: 1.3.0.0 (latest version as of october 8th 2023).

Also the system is set to statically link everything.

Additional context
The problem seems to be with cbits/tracy and it doesn't want to compile because of some kind of problem with symbolic links. There's always a symlink called "obj" in cbites/tracy/build/unix/ and it seems to want to create a directory there named obj and then it fails and crashes.

[tomsmeding]

Two quick questions:

• The cabal.project.local link seems to be broken; is there something interesting in that file?
• What exactly do you mean with this phrase: "Also the system is set to statically link everything."?

[noahmartinwilliams]

Statically link means that it will statically link the libraries instead of using dynamic linking (which is the default for arch linux with haskell).

I'm gonna try attaching the file again:
cabal.project.local.txt

[tomsmeding]

Are those ghc options in the cabal.project.local really necessary? (i.e. what happens if you just remove cabal.project.local?) I would expect cabal to be able to figure out where the package db is that it put there itself in ~/.cabal ... On the other hand, it hardly seems related to your issue.

So with static linking you simply mean that you're using ghcup's ghc/cabal/stack without manually adding -dynamic, and are not using Arch's arguably broken ghc package? :P The assumption is indeed that you aren't using a "broken" ghc, so that sounds good. I was fearing that you meant some global CFLAGS or LDFLAGS or whatever that tells gcc to do all kinds of strange things.

Not at a computer currently; I or someone else will have a look later, hopefully tomorrow.

[noahmartinwilliams]

I was just including every file that I remember making manually. I'm pretty sure there's nothing wrong with gcc and it's linking. Thank you.

[tomsmeding]

Sorry, forgot some stuff.

• Are you using accelerate 1.3.0.0 from Hackage or master from this git repo?
• Can you post the exact terminal output if you cabal clean both here and in the ~/src/package-sources/accelerate folder, and run the cabal build command again, hopefully including the same symlink-related error?

[noahmartinwilliams]

I'm using the latest from github. All packages mentioned in those files are pulled from github (some of which I had to modify in order to get everything to compile, but that's for the accelerate-llvm package and it's dependencies).

errors.txt
stdout.txt

[tomsmeding]

@noahmartinwilliams Can you checkout the setup-symlink branch of accelerate (this PR), and see if that makes it work for you?

[noahmartinwilliams]

That worked. Thank you.

[tomsmeding]

Great! Happy to see that we made the right inference about the cause.

Also thanks for reporting and providing info!