www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Where is ldc.gccbuiltins_x86?

reply Iakh <iaktakh gmail.com> writes:
I'm trying to do

import ldc.gccbuiltins_x86;

but there is no such module
Error: module gccbuiltins_x86 is in file 'ldc/gccbuiltins_x86.d' 
which cannot be read
import path[0] = /usr/include/dlang/ldc/ldc
import path[1] = /usr/include/dlang/ldc
import path[2] = .
ldc failed with exit code 1.

LDC - the LLVM D compiler (0.16.1):
based on DMD v2.067.1 and LLVM 3.7.0

Is there a way to use gccbuiltins (sse2 intrinsics)?
Jan 19
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 20 Jan 2016, at 3:36, Iakh via digitalmars-d-ldc wrote:
 I'm trying to do

 import ldc.gccbuiltins_x86;

 but there is no such module
How did you install LDC? It is supposed to be generated during the LDC build process (${CMAKE_BINARY_DIR}/runtime/gccbuiltins_x86.di) and then copied into ${INCLUDE_INSTALL_DIR}/ldc as part of the installation phase. — David
Jan 20
parent reply Iakh <iaktakh gmail.com> writes:
On Wednesday, 20 January 2016 at 15:53:30 UTC, David Nadlinger 
wrote:
 How did you install LDC?
  — David
It's standard package of Arch Linux. I had installed it with pacman. So if the file is missing is it problem of the packege?
Jan 20
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 20 Jan 2016, at 17:31, Iakh via digitalmars-d-ldc wrote:>
 It's standard package of Arch Linux. I had installed it with pacman.
 So if the file is missing is it problem of the packege?
Yes. I just had a look at https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD, and it seems to manually copy over all the files instead of using the CMake install target. $srcdir/ldc/build/runtime/gccbuiltins*.di seems to be missing from that list. — David
Jan 20
parent reply Dicebot <public dicebot.lv> writes:
On Wednesday, 20 January 2016 at 16:41:47 UTC, David Nadlinger 
wrote:
 On 20 Jan 2016, at 17:31, Iakh via digitalmars-d-ldc wrote:>
 It's standard package of Arch Linux. I had installed it with 
 pacman.
 So if the file is missing is it problem of the packege?
Yes. I just had a look at https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD, and it seems to manually copy over all the files instead of using the CMake install target. $srcdir/ldc/build/runtime/gccbuiltins*.di seems to be missing from that list. — David
btw I wouldn't be able to use cmake install target even if I wanted (I always try to avoid that) because with current CMakeLists.txt it uses system path to bash-completion directory coming from `find_package` and not one inside prefix (unless I am missing another obscure cmake flag) Updated package with gccbuiltins_x86.di will propagate to mirrors soon.
Jan 21
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 22 Jan 2016, at 0:07, Dicebot via digitalmars-d-ldc wrote:
 Updated package with gccbuiltins_x86.di will propagate to mirrors 
 soon.
Thanks!
 btw I wouldn't be able to use cmake install target even if I wanted (I 
 always try to avoid that) because with current CMakeLists.txt it uses 
 system path to bash-completion directory coming from `find_package` 
 and not one inside prefix (unless I am missing another obscure cmake 
 flag)
You are of course free to package stuff in whatever way you find the easiest. But can't you just use "make install DESTDIR=…" like for pretty much every CMake or Autotools project to get exactly what you want? Pretty sure that's recommended in various Arch packaging guides too. If we install files outside that directory, it's definitely a bug in our CMake scripts. — David
Jan 21
parent reply Dicebot <public dicebot.lv> writes:
On Thursday, 21 January 2016 at 23:18:59 UTC, David Nadlinger 
wrote:
 On 22 Jan 2016, at 0:07, Dicebot via digitalmars-d-ldc wrote:
 Updated package with gccbuiltins_x86.di will propagate to 
 mirrors soon.
Thanks!
 btw I wouldn't be able to use cmake install target even if I 
 wanted (I always try to avoid that) because with current 
 CMakeLists.txt it uses system path to bash-completion 
 directory coming from `find_package` and not one inside prefix 
 (unless I am missing another obscure cmake flag)
You are of course free to package stuff in whatever way you find the easiest. But can't you just use "make install DESTDIR=…" like for pretty much every CMake or Autotools project to get exactly what you want? Pretty sure that's recommended in various Arch packaging guides too. If we install files outside that directory, it's definitely a bug in our CMake scripts. — David
I tried using something akin to -DCMAKE_INSTALL_PREFIX=/path/to/pkg but it failed because of that mention bash-completion issue (tried to write to /usr/share/bash-completion). Off-Topic Philosophy: In general it is sort of my personal obsession that goes against usual approach :) I started to do it for two reasons: 1) it forces to learn something about internal project path/file organization (which fits my understanding of packager responsibilities) 2) it encourages to actually improve the layout to make it more fitting for specific distro and provide some useful additions (i.e. systemd service files) Sometimes it results in "oops" moments like this one but I believe overall user experience gets improved a lot. Of course this approach is only viable if one maintains relatively small amount of packages.
Jan 21
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 22 Jan 2016, at 0:39, Dicebot via digitalmars-d-ldc wrote:
 I tried using something akin to -DCMAKE_INSTALL_PREFIX=/path/to/pkg 
 but it failed because of that mention bash-completion issue (tried to 
 write to /usr/share/bash-completion).
-DCMAKE_INSTALL_PREFIX=/path/to/pkg would prepare stuff to be installed to /path/to/pkg, which is not what you actually want for packaging. You wouldn't use --prefix=/path/to/pkg for an autotooled project either. For example, /path/to/pkg might end up being inserted into some config files that way. The bash-completion path issue is another manifestation of that – your system tells us that it wants the completion files in /usr/share/bash-completion, so we'll put them there by default. DESTDIR is different. Its express purpose is to help with packaging (and similar scenarios like installing directly to a specially mounted chroot). For reference, see https://www.gnu.org/prep/standards/html_node/DESTDIR.html and https://wiki.archlinux.org/index.php/Arch_packaging_standards resp. https://wiki.archlinux.org/index.php/Creating_packages. You are doing an awesome job with LDC packaging – thank you! – so I don't doubt that the manual approach works for you. But maybe the usual automatic way will come in handy at some point. ;) — David
Jan 21
parent Dicebot <public dicebot.lv> writes:
On Friday, 22 January 2016 at 00:23:30 UTC, David Nadlinger wrote:
 ..
Thanks! I simply checked some online manual for cmake (haven't used it myself, haven't even known it is in Arch guidelines!) and it mentioned this flag but I most likely have misunderstood its purpose :) Will keep DESTDIR in mind.
Jan 21