[PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ben Woodcroft]

Hi,

This helps compiling when rustc is in one's profile and gcc is not.
Thanks, ben.

[PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ben Woodcroft]

* gnu/packages/rust.scm (rustc)[native-search-paths]: New field.
---
 gnu/packages/rust.scm | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index ae0453004..e1d973ac7 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2016 David Craven <david@craven.ch>
 ;;; Copyright © 2016 Eric Le Bihan <eric.le.bihan.dev@free.fr>
 ;;; Copyright © 2016 ng0 <ng0@libertad.pw>
+;;; Copyright © 2016 Ben Woodcroft <donttrustben@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -272,6 +273,10 @@ rustc-bootstrap and cargo-bootstrap packages.")
                (wrap-program (string-append out "/bin/rustc")
                  `("PATH" ":" prefix (,(string-append ld-wrapper "/bin")))
                  `("LIBRARY_PATH" ":" suffix (,(string-append libc "/lib"))))))))))
+    (native-search-paths
+     (list (search-path-specification
+            (variable "LIBRARY_PATH")
+            (files '("lib" "lib64")))))
     (synopsis "Compiler for the Rust progamming language")
     (description "Rust is a systems programming language that provides memory
 safety and thread safety guarantees.")
-- 
2.11.0

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Hi Ben,

Ben Woodcroft <donttrustben@gmail.com> writes:

> * gnu/packages/rust.scm (rustc)[native-search-paths]: New field.

[...]

> +    (native-search-paths
> +     (list (search-path-specification
> +            (variable "LIBRARY_PATH")
> +            (files '("lib" "lib64")))))

This seems odd. This search path is for glibc, no?

Is the problem this addresses not already fixed by
5d18d776d269ab9a6c44e049936389df3454ba30?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Hi Ben,
>
> Ben Woodcroft <donttrustben@gmail.com> writes:
>
>> * gnu/packages/rust.scm (rustc)[native-search-paths]: New field.
>
> [...]
>
>> +    (native-search-paths
>> +     (list (search-path-specification
>> +            (variable "LIBRARY_PATH")
>> +            (files '("lib" "lib64")))))
>
> This seems odd. This search path is for glibc, no?

It’s honored by GCC (not to be confused with LD_LIBRARY_PATH.)

Does rustc invoke gcc, or does it just happen to use a same-named
variable?

Ludo’.

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ben Woodcroft]

On 28/01/17 09:22, Ludovic Courtès wrote:
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Hi Ben,
>>
>> Ben Woodcroft <donttrustben@gmail.com> writes:
>>
>>> * gnu/packages/rust.scm (rustc)[native-search-paths]: New field.
>> [...]
>>
>>> +    (native-search-paths
>>> +     (list (search-path-specification
>>> +            (variable "LIBRARY_PATH")
>>> +            (files '("lib" "lib64")))))
>> This seems odd. This search path is for glibc, no?
> It’s honored by GCC (not to be confused with LD_LIBRARY_PATH.)
>
> Does rustc invoke gcc, or does it just happen to use a same-named
> variable?
It uses gcc. The specific error I was getting was this:

error: linking with 
`/gnu/store/y1g6991kxvdk4vxhsq07r5saww30v8dq-gcc-4.9.4/bin/gcc` failed: 
exit code: 1
   |
   = note: 
"/gnu/store/y1g6991kxvdk4vxhsq07r5saww30v8dq-gcc-4.9.4/bin/gcc" 
"-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib" 
"/home/ben/git/genome_assigner/target/debug/genome_assigner.0.o" "-o" 
"/home/ben/git/genome_assigner/target/debug/genome_assigner" 
"-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" 
"/home/ben/git/genome_assigner/target/debug/deps" "-L" 
"/home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/rust-htslib-0.10.0/htslib" 
"-L" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib" 
"-Wl,-Bstatic" "-Wl,-Bdynamic" 
"/home/ben/git/genome_assigner/target/debug/deps/librust_htslib-ccb3e9d7adc535c1.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libitertools-42383a1bef75ce72.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libcustom_derive-bf1b4c7d3ee792c6.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libieee754-afaaaec92cb01ddb.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/liblazy_static-3a04918be71c80ee.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libquick_error-729eced693f2612d.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/liblibc-29ef97a68464c2b7.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/liburl-30c51e30991892cc.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libnewtype_derive-154c397f9f0bae71.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libidna-82ebdb343d6c1855.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libunicode_normalization-77ce7c413abacd3f.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libunicode_bidi-eaf420bc9a69d19f.rlib" 
"/home/ben/git/genome_assigner/target/debug/deps/libmatches-3614821dd5ceb75c.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-f5a209a9.rlib" 
"/gnu/store/8mdrn8i530qh00l4xsmjlj1q7mzsj5a0-rustc-1.14.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-f5a209a9.rlib" 
"-l" "z" "-l" "util" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" 
"pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util"
   = note: ld: cannot find -lz
collect2: error: ld returned 1 exit status


Thanks, ben.

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ludovic Courtès]

Hi Ben,

Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:

> On 28/01/17 09:22, Ludovic Courtès wrote:
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> Hi Ben,
>>>
>>> Ben Woodcroft <donttrustben@gmail.com> writes:
>>>
>>>> * gnu/packages/rust.scm (rustc)[native-search-paths]: New field.
>>> [...]
>>>
>>>> +    (native-search-paths
>>>> +     (list (search-path-specification
>>>> +            (variable "LIBRARY_PATH")
>>>> +            (files '("lib" "lib64")))))
>>> This seems odd. This search path is for glibc, no?
>> It’s honored by GCC (not to be confused with LD_LIBRARY_PATH.)
>>
>> Does rustc invoke gcc, or does it just happen to use a same-named
>> variable?
> It uses gcc.

In that case, you can copy GCC’s search paths wholesale:

  ;; rustc invokes gcc, so we need to set its search paths accordingly.
  (native-search-paths (package-native-search-paths gcc))

HTH!

Ludo’.

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ben Woodcroft]

Hi Marius,


On 28/01/17 06:21, Marius Bakke wrote:
> Hi Ben,
>
> Ben Woodcroft <donttrustben@gmail.com> writes:
>
>> * gnu/packages/rust.scm (rustc)[native-search-pat hs]: New field.
> [...]
>
>> +    (native-search-paths
>> +     (list (search-path-specification
>> +            (variable "LIBRARY_PATH")
>> +            (files '("lib" "lib64")))))
> This seems odd. This search path is for glibc, no?
>
> Is the problem this addresses not already fixed by
> 5d18d776d269ab9a6c44e049936389df3454ba30?

I didn't have any problem compiling and linking pure rust programs - 
that commit fixed that issue, but when trying to link rust programs to 
non-rust libraries such as zlib the linker did not look in the lib of 
the profile (unless gcc was also in the profile, I guess). I was 
specifically looking to include rust-htslib in a crate I am building, to 
be concrete.

Thanks, ben.

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

Ben Woodcroft <b.woodcroft@uq.edu.au> writes:

> I didn't have any problem compiling and linking pure rust programs - 
> that commit fixed that issue, but when trying to link rust programs to
> non-rust libraries such as zlib the linker did not look in the lib of
> the profile (unless gcc was also in the profile, I guess). I was
> specifically looking to include rust-htslib in a crate I am building,
> to be concrete.

I'm not too familiar with rust, but isn't the linker supposed to look in
the store, not in your user profiler?  My understanding is that we
usually don't want to compose components dynamically like that, since it
causes problems (e.g., incomplete deployment due to "missing" stuff in
the user's profile).

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH] gnu: rustc: Add LIBRARY_PATH search path.

[Ben Woodcroft]

On 29/01/17 11:57, Chris Marusich wrote:
> Ben Woodcroft <b.woodcroft@uq.edu.au> writes:
>
>> I didn't have any problem compiling and linking pure rust programs -
>> that commit fixed that issue, but when trying to link rust programs to
>> non-rust libraries such as zlib the linker did not look in the lib of
>> the profile (unless gcc was also in the profile, I guess). I was
>> specifically looking to include rust-htslib in a crate I am building,
>> to be concrete.
> I'm not too familiar with rust, but isn't the linker supposed to look in
> the store, not in your user profiler?  My understanding is that we
> usually don't want to compose components dynamically like that, since it
> causes problems (e.g., incomplete deployment due to "missing" stuff in
> the user's profile).

I'm not too familiar either, but I think of it like this.

Imagine we had a hypothetical rust-no-gcc-build-system for building rust 
packages which did not inherit from gnu-build-system so did not have gcc 
as an input. Then, building rust packages which linked to libraries such 
as zlib would not work, even if zlib were specified as an input, because 
LIBRARY_PATH is not set. In that case, the compilation/linking with rust 
is much like compilation/linking with gcc - it requires LIBRARY_PATH.

Does that make sense?
Thanks, ben.