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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016