Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 08 21:50
    kinke commented #3882
  • Dec 08 21:50

    kinke on master

    wasm: Add new default lld switc… (compare)

  • Dec 08 21:50
    kinke closed #3882
  • Dec 08 21:49
    kinke auto_merge_disabled #3882
  • Dec 08 19:37
    kinke auto_merge_enabled #3882
  • Dec 08 19:37
    kinke edited #3882
  • Dec 08 19:34
    ryuukk commented #3882
  • Dec 08 19:34
    ryuukk synchronize #3882
  • Dec 08 19:06
    kinke commented #3882
  • Dec 08 19:03
    ryuukk commented #3882
  • Dec 08 19:03
    ryuukk synchronize #3882
  • Dec 08 18:59
    kinke commented #3882
  • Dec 08 18:50
    ryuukk commented #3882
  • Dec 07 19:50
    ryuukk synchronize #3882
  • Dec 07 19:39
    kinke commented #3882
  • Dec 07 19:38
    kinke commented #3882
  • Dec 07 17:43
    JohanEngelen commented #3882
  • Dec 07 17:41
    JohanEngelen commented #3882
  • Dec 07 17:41
    JohanEngelen commented #3882
  • Dec 07 15:06
    Geod24 commented #3882
Gratian Lup
@gratianlup
Hi, I'm working on a tool that is extremely useful for working with compiler IR and the plan is to open source it next year (I work on the MSVC optimizer). It's a Windows-based UI tool, but does work well on Linux using Wine with a couple of distributions I tried, including Ubuntu. What I wonder is what OS most LLVM devs use and if there was ever such a survey done? I assume most are not using Windows, but do wonder about the Linux/Mac OS split, and then for Linux what distro. If I'd make a survey, would people answer to it? :) Knowing this would help making sure the tool works fine for LLVM devs
Petar Kirov
@PetarKirov
I'm not an LLVM dev, but I'd say that the distribution is similar to the general distribution of developers. Some of the most popular distros are: Ubuntu, Debian, Arch Linux, NixOS, Fedora, Gentoo, to name a fee.
to name a few*
If you're building a UI app, I suggest using a cross-platform UI framework. @gratianlup what did you use?
Jon Degenhardt
@jondegenhardt
Does the Arch Linux pacman distribution of LDC include the LTO versions of the phobos and druntime libraries? A tsv-utils user is trying to build on Arch Linux using the -flto=thin -defaultlib=phobos2-ldc-lto,druntime-ldc-lto flags and getting failures to find libraries. This is when using the Arch Linux LDC distribution. It works when building with the packages provided on the GitHub releases page. I'm guessing the Arch Linux may simply not include the LTO versions of these libraries, but I'm not an Arch Linux user, so not sure.
Jon Degenhardt
@jondegenhardt
Another possibility is that the LTO versions of the libraries are included, but the Arch Linux ldc2.conf file is not setup correctly to support these build options.
Martin Kinkelin
@kinke
According to the files list of https://archlinux.org/packages/community/x86_64/liblphobos, the libs are included, so it's probably an ldc2.conf issue. The user might need to add -link-defaultlib-shared=false if it defaults to true in the config.
Jon Degenhardt
@jondegenhardt
Thanks @kinke !
Jon Degenhardt
@jondegenhardt
@kinke FYI - Turned out to be two issues on Archlinux. As suggested, one was setting -link-defaultlib-shared=false to override the ldc2.conf file. The other was change the Archlinux builds of druntime and phobos libs to avoid stripping symbols.
Imperatorn
@Imperatorn
Omg there's also gitter? Not just IRC, Discord, Slack and forums 😱
Solomon Choina
@SolarAquarion
https://gist.github.com/SolarAquarion/55dac59b006da691921166196c3083c9 i'm getting a build failure, of course i'm using llvm-git to build it
so hat may be a problem
Solomon Choina
@SolarAquarion
/home/solaraquarion/ldc-git/src/ldc/gen/dibuilder.cpp:197:23: error: call to non-static member function without an object argument
llvm::DebugLoc::get(loc.linnum, getColumn(loc), GetCurrentScope());
~~~~^~~
/home/solaraquarion/ldc-git/src/ldc/gen/dibuilder.cpp:205:23: error: call to non-static member function without an object argument
llvm::DebugLoc::get(loc.linnum, getColumn(loc), GetCurrentScope());
~~~~^~~
/home/solaraquarion/ldc-git/src/ldc/gen/dibuilder.cpp:1206:23: error: call to non-static member function without an object argument
llvm::DebugLoc::get(linnum, col, GetCurrentScope()));
~~~~^~~
3 errors generated.
that's a better error message
Marcelo Silva Nascimento Mancini
@MrcSnm

Hello.
Is there some way I could select a specific GCC for using with LDC? I remember people saying about D and C binary compatibility but I can't seem to find it:

I have tried inputting some thing onto ldc conf as:

"thumb-agb-elf-gcc":
{
switches = [
"-link-defaultlib-shared=false",
"-gcc=C:/Users/Hipreme/Documents/GBA/devkitadv/bin/arm-agb-elf-gcc.exe",
];
rpath = "";
};

I know it is a very old arm, (arm3 or 4, dont remember right now), even testing it with the "arm" as the system, I keep getting "File format not recognized", what I'm misssing?

Martin Kinkelin
@kinke
Hey; yes, -gcc is the correct way. You might have to find the proper -mtriple (e.g., the -gcc suffix shouldn't be needed) for LLVM to emit objects of a compatible format (and make sure to name the .conf section accordingly).
Marcelo Silva Nascimento Mancini
@MrcSnm
Proper -mtriple?
What if I get some arch that is not documented to be supported?
Martin Kinkelin
@kinke
How are you trying to cross-compile? What do you mean by testing it with the "arm" as the system?
Marcelo Silva Nascimento Mancini
@MrcSnm

I'm trying to compile for a game boy advance, which is a ARM7TDMI, whose is described as : 32-bit RISC ARM processor.
Instruction set: ARM (32-bit), Thumb (16-bit) (ARMv4T)
Arm as the system is by doing:

arm-agb-elf-gcc instead of thumb-agb-elf-gcc at the config file

Martin Kinkelin
@kinke
If I understand correctly, you've only added that .conf section and expect it to cross-compile to that target by default now. See https://wiki.dlang.org/Cross-compiling_with_LDC for how this works - you'll need something like ldc2 -mtriple=thumb-agb-elf and a section named accordingly, e.g., thumb.*-agb.
Marcelo Silva Nascimento Mancini
@MrcSnm

Yea, actually I was doing like that, there is 2 problems:

1:When only doing that it fails to locate CC, so I do -gcc= at the ldc2 build cmd and it tries to compile
2:My gcc does not recognize the obj generated

ldc2 -mtriple=thumb-agb-elf -betterC hello.d -of=hello.elf is my cmd
Marcelo Silva Nascimento Mancini
@MrcSnm

Those are my readelf from .o generated
D Elf generated from thumb:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          924 (bytes into file)
  Flags:                             0x5000000, <unrecognized EABI>
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         9
  Section header string table index: 1

C Elf:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          780 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         10
  Section header string table index: 7

D elf generated from ARM:

  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          1028 (bytes into file)
  Flags:                             0x5000000, <unrecognized EABI>
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         9
  Section header string table index: 1
Martin Kinkelin
@kinke

1:When only doing that it fails to locate CC

Then your section name doesn't correspond to the normalized triple. See the ldc2.conf comments.

My gcc does not recognize the obj generated

That's what I meant by 'you might have to find the proper -mtriple'. It's the one you would have to use as clang -target switch to target the GBA.

Marcelo Silva Nascimento Mancini
@MrcSnm

1:When only doing that it fails to locate CC

Then your section name doesn't correspond to the normalized triple. See the ldc2.conf comments.

My gcc does not recognize the obj generated

That's what I meant by 'you might have to find the proper -mtriple'. It's the one you would have to use as clang -target switch to target the GBA.

1: Oh, found right now that my ldc2.conf was actually inside %APPDATA% instead of C:/ldc2/etc/

2: Yea, I think the current registered architectures don't contain what I would need for gba, which would be the armv4t. Is there some way to compile for this arch?

Martin Kinkelin
@kinke
2: I doubt the arch is the problem (you could try something like armv4 too). Based on your posted ELF headers, I guess it's rather the OS/ABI part. I suggest trying to google the corresponding GBA clang -target. Or grepping the LLVM src for -gba-.
Marcelo Silva Nascimento Mancini
@MrcSnm

2: I doubt the arch is the problem (you could try something like armv4 too). Based on your posted ELF headers, I guess it's rather the OS/ABI part. I suggest trying to google the corresponding GBA clang -target. Or grepping the LLVM src for -gba-.

Ive found out people saying that the actual triple would be arm-none-eabi, do you know how would I achieve that?

Martin Kinkelin
@kinke
I guess that's simply -mtriple=arm--none-eabi, which is normalized to arm-unknown-none-eabi (for the ldc2.conf section name).
Marcelo Silva Nascimento Mancini
@MrcSnm
Humm now Im getting some undefined references to libc like _sbrk, _kill and those things
Imperatorn
@Imperatorn
Lol how many places do we have where we discuss D? Forum, Discord, Slack, IRC and Gitter? Are there more?
Martin Kinkelin
@kinke
GitHub as probably the most important of all?
Imperatorn
@Imperatorn
Question from Discord:
"Hey why did work on Calypso stop btw?
Seemed pretty wild to just import <C++ namespace> with no type defs/bindings written"