Jump to page: 1 2
Thread overview
Fail to set LD_LIBRARY_PATH then cross build for ARM
Aug 01
Oleg B
Aug 01
Oleg B
Aug 01
Joakim
Aug 01
Oleg B
Aug 01
Joakim
Aug 01
Oleg B
Aug 01
Joakim
Aug 02
Oleg B
Aug 02
Joakim
Aug 02
Oleg B
Aug 02
Joakim
Aug 03
kinke
August 01
I try build simple program for ARM use this instruction https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux#Build_a_command-line_executable

In my system it's looks like this:

  ldc2 -v -mtriple=arm-linux-gnueabihf -gcc=/usr/bin/arm-linux-gnueabihf-gcc test.d

Building fails because ldc2 use /usr/lib64 as library path and I get this message:

  /usr/bin/arm-linux-gnueabihf-gcc test.o -o test -L/usr/lib64 -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm
  /usr/lib64/libphobos2-ldc.so: file not recognized: File format not recognized
  collect2: error: ld returned 1 exit status
  Error: /usr/bin/arm-linux-gnueabihf-gcc failed with status: 1

If I copy first line and replace -L flag to ldc2's arm building dir (I build ldc2 on arm) like this

  -L/home/deviator/Documents/ldc_build_arm/lib

gcc use this path and build and link my program!

I try to set LD_LIBRARY_PATH variable but it's have no effect.
Is possible to set -L flag through ldc2 arguments?
August 01
> Is possible to set -L flag through ldc2 arguments?

-L-L flag can add library path

  ldc2 -v -L-L/home/deviator/Documents/ldc_build_arm/lib -mtriple=arm-linux-gnueabihf -gcc=/usr/bin/arm-linux-gnueabihf-gcc test.d

but it's fails too

/usr/bin/arm-linux-gnueabihf-gcc test.o -o test -L/usr/lib64 -L/home/deviator/Documents/ldc_build_arm/lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm
/usr/lib64/libphobos2-ldc.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
Error: /usr/bin/arm-linux-gnueabihf-gcc failed with status: 1

only if remove default -L/usr/lib64 it's work
August 01
On Tuesday, 1 August 2017 at 14:39:27 UTC, Oleg B wrote:
>> Is possible to set -L flag through ldc2 arguments?
>
> -L-L flag can add library path
>
>   ldc2 -v -L-L/home/deviator/Documents/ldc_build_arm/lib -mtriple=arm-linux-gnueabihf -gcc=/usr/bin/arm-linux-gnueabihf-gcc test.d
>
> but it's fails too
>
> /usr/bin/arm-linux-gnueabihf-gcc test.o -o test -L/usr/lib64 -L/home/deviator/Documents/ldc_build_arm/lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm
> /usr/lib64/libphobos2-ldc.so: file not recognized: File format not recognized
> collect2: error: ld returned 1 exit status
> Error: /usr/bin/arm-linux-gnueabihf-gcc failed with status: 1
>
> only if remove default -L/usr/lib64 it's work

Could you explain your build environment a bit: you're cross-compiling from linux/x64 to linux/armhf?  Using the old compiler built from source as on that wiki page, or by using the official pre-built release build of ldc?  The former shouldn't add /usr/lib64 to your linker path.  Maybe you mean to run the former but are running the latter by mistake.
August 01
On Tuesday, 1 August 2017 at 16:23:00 UTC, Joakim wrote:
> Could you explain your build environment a bit: you're cross-compiling from linux/x64 to linux/armhf?  Using the old compiler built from source as on that wiki page, or by using the official pre-built release build of ldc?  The former shouldn't add /usr/lib64 to your linker path.  Maybe you mean to run the former but are running the latter by mistake.

host:

linux 4.11.11-300.fc26.x86_64

ldc2 from official pre-build release from github
LDC - the LLVM D compiler (1.3.0):
  based on DMD v2.073.2 and LLVM 4.0.0
  built with LDC - the LLVM D compiler (1.3.0)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

target:

linux 4.9.35-v7+ armv7l (raspbian)

ldc2 compiled from git (1.4.0git-02d2a2c)
based on DMD v2.073.2 and LLVM 3.9.0
August 01
On Tuesday, 1 August 2017 at 17:26:16 UTC, Oleg B wrote:
> On Tuesday, 1 August 2017 at 16:23:00 UTC, Joakim wrote:
>> Could you explain your build environment a bit: you're cross-compiling from linux/x64 to linux/armhf?  Using the old compiler built from source as on that wiki page, or by using the official pre-built release build of ldc?  The former shouldn't add /usr/lib64 to your linker path.  Maybe you mean to run the former but are running the latter by mistake.
>
> host:
>
> linux 4.11.11-300.fc26.x86_64
>
> ldc2 from official pre-build release from github
> LDC - the LLVM D compiler (1.3.0):
>   based on DMD v2.073.2 and LLVM 4.0.0
>   built with LDC - the LLVM D compiler (1.3.0)
>   Default target: x86_64-unknown-linux-gnu
>   Host CPU: skylake
>
> target:
>
> linux 4.9.35-v7+ armv7l (raspbian)
>
> ldc2 compiled from git (1.4.0git-02d2a2c)
> based on DMD v2.073.2 and LLVM 3.9.0

You just listed two different compilers: do you mean you used a prebuilt ldc 1.3 on linux/x64 to build an ldc 1.4 cross-compiler on linux/x64 for armhf from source?  If so, maybe you're invoking the wrong one, ie you should run ./ldc_build_arm/bin/ldc2 not ldc2 when cross-compiling.

Are you patching ldc 1.4 at all?
That old patch linked from the wiki won't work.
August 01
On Tuesday, 1 August 2017 at 18:34:24 UTC, Joakim wrote:
> You just listed two different compilers: do you mean you used a prebuilt ldc 1.3 on linux/x64 to build an ldc 1.4 cross-compiler on linux/x64 for armhf from source?  If so, maybe you're invoking the wrong one, ie you should run ./ldc_build_arm/bin/ldc2 not ldc2 when cross-compiling.

ldc2 for ARM I build from sources before 1.3.0 release (I don't know why version is 1.4.0) and build it direct on raspberry by ldc2-1.1.0. From ARM I only use builded libraries (phobos and druntime), not a compiler.

> Are you patching ldc 1.4 at all? That old patch linked from the wiki won't work.

I don't patch ldc anywhere, not on host, not on target.
August 01
On Tuesday, 1 August 2017 at 18:44:03 UTC, Oleg B wrote:
> On Tuesday, 1 August 2017 at 18:34:24 UTC, Joakim wrote:
>> You just listed two different compilers: do you mean you used a prebuilt ldc 1.3 on linux/x64 to build an ldc 1.4 cross-compiler on linux/x64 for armhf from source?  If so, maybe you're invoking the wrong one, ie you should run ./ldc_build_arm/bin/ldc2 not ldc2 when cross-compiling.
>
> ldc2 for ARM I build from sources before 1.3.0 release (I don't know why version is 1.4.0) and build it direct on raspberry by ldc2-1.1.0. From ARM I only use builded libraries (phobos and druntime), not a compiler.

It is not clear what you're trying to do.  You want to use the ldc 1.3 compiler on linux/x64 to cross-compile to linux/armhf?  To do this, you are building the ldc 1.4 libraries natively on linux/armhf, then copying them over to linux/x64 and trying to use them with ldc 1.3?  If you have a working ldc 1.4 on your Raspberry/ARM board, why not just use that?  Please detail exactly what you're doing, as you seem to be trying something unusual.
August 02
On Tuesday, 1 August 2017 at 20:18:43 UTC, Joakim wrote:
> It is not clear what you're trying to do. You want to use the ldc 1.3 compiler on linux/x64 to cross-compile to linux/armhf?

Yes.

> To do this, you are building the ldc 1.4 libraries natively on linux/armhf, then copying them over to linux/x64 and trying to use them with ldc 1.3?

Yes, I build master ldc some time ago (before 1.3.0 release) and it have version 1.4.0 (it's not master now, I say master because it was not a tag and I don't know why developers names it 1.4.0) and it's very long time building. Now I only try using builded libs. If they did not work, I must be rebuild they. But they work! And working druntime and phobos isn't a question.

> If you have a working ldc 1.4 on your Raspberry/ARM board, why
> not just use that?

Because rpi2 have 1GB RAM, building gtk-d need more 1.6 GB RAM.
For code without gtk-d building is very slow.

> Please detail exactly what you're doing, as you seem to be trying something unusual.

I try build my soft on rpi.

Main question is how to specify dir with ARM version of druntime and phobos and remove default dir from call extern gcc compiler? Default dir is /usr/lib64 and it contains druntime and phobos (x86_64). Additional dir not scans because build fails while trying loading existing x86_64 libs.
August 02
On Wednesday, 2 August 2017 at 00:46:01 UTC, Oleg B wrote:
> On Tuesday, 1 August 2017 at 20:18:43 UTC, Joakim wrote:
>> It is not clear what you're trying to do. You want to use the ldc 1.3 compiler on linux/x64 to cross-compile to linux/armhf?
>
> Yes.
>
>> To do this, you are building the ldc 1.4 libraries natively on linux/armhf, then copying them over to linux/x64 and trying to use them with ldc 1.3?
>
> Yes, I build master ldc some time ago (before 1.3.0 release) and it have version 1.4.0 (it's not master now, I say master because it was not a tag and I don't know why developers names it 1.4.0) and it's very long time building. Now I only try using builded libs. If they did not work, I must be rebuild they. But they work! And working druntime and phobos isn't a question.
>
>> If you have a working ldc 1.4 on your Raspberry/ARM board, why
>> not just use that?
>
> Because rpi2 have 1GB RAM, building gtk-d need more 1.6 GB RAM.
> For code without gtk-d building is very slow.
>
>> Please detail exactly what you're doing, as you seem to be trying something unusual.
>
> I try build my soft on rpi.
>
> Main question is how to specify dir with ARM version of druntime and phobos and remove default dir from call extern gcc compiler? Default dir is /usr/lib64 and it contains druntime and phobos (x86_64). Additional dir not scans because build fails while trying loading existing x86_64 libs.

OK, got it, would have helped a lot if you'd explained all this from the beginning.  I'm guessing you're using ldc 1.3 installed by your distro's package manager, as I don't see any lib64 in the ldc download, so your distro packages a ldc2.conf that adds the lib64 path.  You can make sure by looking at /usr/etc/ldc2.conf, or wherever your distro puts that config file, and looking for lib64 in there.

You're probably best off creating a .ldc/ldc2.conf in your home directory, with the specific config you want for linux/armhf.  See this previous post for an example:

http://forum.dlang.org/post/skdqeursuheqdsermmwh@forum.dlang.org

We're working on making it much simpler to cross-compile the stdlib for the next ldc 1.4 beta, see kinke's latest patch here:

https://github.com/ldc-developers/ldc/pull/2253

I'm not sure how well your approach will work, as the ldc 1.4 stdlib may not work with ldc 1.3.  I'll be submitting a PR soon that should make it even easier, so you may want to wait for the next 1.4 beta instead.
August 02
On Wednesday, 2 August 2017 at 03:28:48 UTC, Joakim wrote:
> OK, got it, would have helped a lot if you'd explained all this from the beginning.

My mistake, sorry.

> I'm guessing you're using ldc 1.3 installed by your distro's package manager, as I don't see any lib64 in the ldc download, so your distro packages a ldc2.conf that adds the lib64 path.  You can make sure by looking at /usr/etc/ldc2.conf, or wherever your distro puts that config file, and looking for lib64 in there.
> You're probably best off creating a .ldc/ldc2.conf in your home directory, with the specific config you want for linux/armhf.

Thank you! I found -L/usr/lib64 switch in /etc/ldc2.conf. In .ldc/ldc2.conf I configure build for arm and it's work!
Question about it: why '.ldc'? Why not '.config/' dir?

> See this previous post for an example:
>
> http://forum.dlang.org/post/skdqeursuheqdsermmwh@forum.dlang.org

Cool! But I don't understand how it use through dub. Dub don't know about any arch expect x86(_64). If add dflags "-march=arm" or something like this in dub.sdl it applies only for building package, not for dependencies. Building without dub is some painful for me and it's not useful to change .ldc/ldc2.conf when need arm and when need x86... Maybe I do something wrong?

> We're working on making it much simpler to cross-compile the stdlib for the next ldc 1.4 beta, see kinke's latest patch here:
>
> https://github.com/ldc-developers/ldc/pull/2253

I'm looking forward to full cross-building. It's plained? Or always be need external cross-linker?

> I'm not sure how well your approach will work, as the ldc 1.4 stdlib may not work with ldc 1.3.  I'll be submitting a PR soon that should make it even easier, so you may want to wait for the next 1.4 beta instead.

Can't wait 1.4 beta, business does not wait =)
« First   ‹ Prev
1 2