Jump to page: 1 2
Thread overview
How can I build LDC v1.18.0?
Oct 29
Sobaya
Oct 29
kinke
Oct 29
Sobaya
Oct 29
kinke
Oct 30
Sobaya
Oct 30
Sobaya
Oct 30
kinke
Oct 30
Sobaya
Oct 29
Sobaya
October 29
I'm working on building LDC in tag v1.18.0.

I cloned LDC with `--recursive`  option, checked out tag v1.18.0, and execute cmake like below:

```
mkdir build
cd build
cmake ..
```

But I got the error in cmake execution:
```
CMake Error at /usr/lib/cmake/llvm/LLVMExports.cmake:37 (message):
  Some (but not all) targets in this export set were already defined.

  Targets Defined: FileCheck;not

  Targets not yet defined:
....
```

After investigating, I found the cause is that cmake target "FileCheck`" and "not" are already defined in "ldc/utils/CMakeLists.txt`".
I thought that "ldc/utils/CMakeLists.txt`" is written to be loaded after including LLVMConfig because there are some checks for existence of those targets, which is defined in LLVMConfig.
But actually "ldc/utils/CMakeLists.txt`" is loaded before LLVMConfig.
I cannot understand why this can be built.

What should I do for building LDC successfully?

My operating system is Arch Linux and LLVM version is 9.0.0.
October 29
On 2019-10-29 08:04, Sobaya wrote:
> I'm working on building LDC in tag v1.18.0.
> 
> I cloned LDC with `--recursive`  option, checked out tag v1.18.0, and execute cmake like below:
> 
> ```
> mkdir build
> cd build
> cmake ..
> ```
> 
> But I got the error in cmake execution:
> ```
> CMake Error at /usr/lib/cmake/llvm/LLVMExports.cmake:37 (message):
>    Some (but not all) targets in this export set were already defined.
> 
>    Targets Defined: FileCheck;not
> 
>    Targets not yet defined:
> ....
> ```
> 
> After investigating, I found the cause is that cmake target "FileCheck`" and "not" are already defined in "ldc/utils/CMakeLists.txt`".
> I thought that "ldc/utils/CMakeLists.txt`" is written to be loaded after including LLVMConfig because there are some checks for existence of those targets, which is defined in LLVMConfig.
> But actually "ldc/utils/CMakeLists.txt`" is loaded before LLVMConfig.
> I cannot understand why this can be built.
> 
> What should I do for building LDC successfully?
> 
> My operating system is Arch Linux and LLVM version is 9.0.0.

Not sure if it's related, but you need to run "git submodule update --recursive" after checking out a tag.

-- 
/Jacob Carlborg
October 29
On Tuesday, 29 October 2019 at 13:21:49 UTC, Jacob Carlborg wrote:
> On 2019-10-29 08:04, Sobaya wrote:

Where's the original msg? It doesn't show up in the web interface.

>> After investigating, I found the cause is that cmake target "FileCheck`" and "not" are already defined in "ldc/utils/CMakeLists.txt`".
>> I thought that "ldc/utils/CMakeLists.txt`" is written to be loaded after including LLVMConfig because there are some checks for existence of those targets, which is defined in LLVMConfig.
>> But actually "ldc/utils/CMakeLists.txt`" is loaded before LLVMConfig.
>> I cannot understand why this can be built.

Looks like it depends on how LLVM was built plus it seems LLVM 9 related. It works fine with our prebuilt LLVM 9 as well as the official prebuilt LLVM 9 from llvm.org.
This (https://github.com/ldc-developers/ldc/issues/3079) and similar CMake issues are fixed in master now (see https://github.com/ldc-developers/ldc/pull/3198).
October 29
On Tuesday, 29 October 2019 at 13:21:49 UTC, Jacob Carlborg wrote:
> On 2019-10-29 08:04, Sobaya wrote:
>> [...]
>
> Not sure if it's related, but you need to run "git submodule update --recursive" after checking out a tag.

I've already run recursive submodule update.
October 29
On Tuesday, 29 October 2019 at 13:55:28 UTC, kinke wrote:
> On Tuesday, 29 October 2019 at 13:21:49 UTC, Jacob Carlborg wrote:
>> On 2019-10-29 08:04, Sobaya wrote:
>
> Where's the original msg? It doesn't show up in the web interface.
>
>>> [...]
>
> Looks like it depends on how LLVM was built plus it seems LLVM 9 related. It works fine with our prebuilt LLVM 9 as well as the official prebuilt LLVM 9 from llvm.org.
> This (https://github.com/ldc-developers/ldc/issues/3079) and similar CMake issues are fixed in master now (see https://github.com/ldc-developers/ldc/pull/3198).

Surely I succeeded on master branch, but why this bug is remained at release tag?
October 29
On Tuesday, 29 October 2019 at 18:12:36 UTC, Sobaya wrote:
> Surely I succeeded on master branch, but why this bug is remained at release tag?

1.18 is 13 days old, the fix was merged 8 days ago, and the latent issue has been there for months if not years and has only become acute now with, as explained, *some* LLVM 9 configs.
October 30
On Tuesday, 29 October 2019 at 19:36:49 UTC, kinke wrote:
> On Tuesday, 29 October 2019 at 18:12:36 UTC, Sobaya wrote:
>> Surely I succeeded on master branch, but why this bug is remained at release tag?
>
> 1.18 is 13 days old, the fix was merged 8 days ago, and the latent issue has been there for months if not years and has only become acute now with, as explained, *some* LLVM 9 configs.

Thank you.
Then I'll try to work in master branch.
October 30
On 2019-10-29 14:55, kinke wrote:

> Where's the original msg? It doesn't show up in the web interface.

I don't know. I'm using the newsgroup interface.

-- 
/Jacob Carlborg
October 30
On Wednesday, 30 October 2019 at 04:08:18 UTC, Sobaya wrote:
> On Tuesday, 29 October 2019 at 19:36:49 UTC, kinke wrote:
>> On Tuesday, 29 October 2019 at 18:12:36 UTC, Sobaya wrote:
>>> Surely I succeeded on master branch, but why this bug is remained at release tag?
>>
>> 1.18 is 13 days old, the fix was merged 8 days ago, and the latent issue has been there for months if not years and has only become acute now with, as explained, *some* LLVM 9 configs.
>
> Thank you.
> Then I'll try to work in master branch.

I tried but get an error "Option 'mc-relax-all' registered more than once!".
October 30
On Wednesday, 30 October 2019 at 12:07:50 UTC, Sobaya wrote:
> I tried but get an error "Option 'mc-relax-all' registered more than once!".

See https://wiki.dlang.org/Building_LDC_from_source - you'll need to set LDC_WITH_LLD=OFF (I guess you're linking against the shared LLVM library...).
« First   ‹ Prev
1 2