Better support for `--llvm-root`. #27937

Merged
merged 1 commit into from Dec 14, 2015

Conversation

Projects
None yet
7 participants
@DiamondLovesYou
Contributor

DiamondLovesYou commented Aug 22, 2015

This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with LD_LIBRARY_PATH etc).

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Aug 22, 2015

Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Aug 22, 2015

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

mk/tests.mk
- $$(S)
+ $$(S) \
+ "$$(LLVM_LIBDIR_RUSTFLAGS_$(3))" \
+ "$$(shell $$(LLVM_CONFIG_$(3)) --components)"

This comment has been minimized.

@alexcrichton

alexcrichton Aug 24, 2015

Member

Can this output be cached in a variable to prevent re-running it?

@alexcrichton

alexcrichton Aug 24, 2015

Member

Can this output be cached in a variable to prevent re-running it?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Aug 25, 2015

Contributor

Done.

src/librustc_llvm/lib.rs
@@ -2327,6 +2328,37 @@ pub unsafe fn debug_loc_to_string(c: ContextRef, tr: DebugLocRef) -> String {
.expect("got a non-UTF8 DebugLoc from LLVM")
}
+pub fn initialize_available_targets() {
+ macro_rules! init_target(
+ ($cfg:ident $fn_name:ident) => { {

This comment has been minimized.

@alexcrichton

alexcrichton Aug 24, 2015

Member

The fn_name ident may be better named arch_name

@alexcrichton

alexcrichton Aug 24, 2015

Member

The fn_name ident may be better named arch_name

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Aug 25, 2015

Contributor

Yeah, silly me. Done.

@DiamondLovesYou

DiamondLovesYou Aug 25, 2015

Contributor

Yeah, silly me. Done.

mk/llvm.mk
@@ -83,7 +83,7 @@ endif
LLVM_LINKAGE_PATH_$(1):=$$(abspath $$(RT_OUTPUT_DIR_$(1))/llvmdeps.rs)
$$(LLVM_LINKAGE_PATH_$(1)): $(S)src/etc/mklldeps.py $$(LLVM_CONFIG_$(1))
$(Q)$(CFG_PYTHON) "$$<" "$$@" "$$(LLVM_COMPONENTS)" "$$(CFG_ENABLE_LLVM_STATIC_STDCPP)" \
- $$(LLVM_CONFIG_$(1))
+ "$$(CFG_ENABLE_LLVM_LIBCPP)" $$(LLVM_CONFIG_$(1))

This comment has been minimized.

@alexcrichton

alexcrichton Aug 24, 2015

Member

In the configure script it looks like this is CFG_ENABLE_LIBCPP instead of LLVM_LIBCPP, was this defined elsewhere though?

@alexcrichton

alexcrichton Aug 24, 2015

Member

In the configure script it looks like this is CFG_ENABLE_LIBCPP instead of LLVM_LIBCPP, was this defined elsewhere though?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Aug 24, 2015

Contributor

Actually it's worse than that: configure doesn't even putvar anything related to libcpp. Nice catch, thanks.

@DiamondLovesYou

DiamondLovesYou Aug 24, 2015

Contributor

Actually it's worse than that: configure doesn't even putvar anything related to libcpp. Nice catch, thanks.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 24, 2015

Member

The travis failures here look like they may not be benign

Member

alexcrichton commented Aug 24, 2015

The travis failures here look like they may not be benign

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 25, 2015

Member

Can this hold off on the changes to tests/maketest for now? The changes to compiletest are only needed if tests are linking to the compiler (e.g. fulldeps), but for most targets with custom LLVM builds we probably don't need the compiler itself working there just yet, so fixes like this can come later if absolutely necessary. Same with the changes to run-make as I believe run-make isn't run for target-only targets (as opposed to host+target targets).

I continue to be very wary of landing all these changes as it's quite a deal of difficult logic that isn't tested in any way, so I prefer to minimize the impact as much as possible.

Member

alexcrichton commented Aug 25, 2015

Can this hold off on the changes to tests/maketest for now? The changes to compiletest are only needed if tests are linking to the compiler (e.g. fulldeps), but for most targets with custom LLVM builds we probably don't need the compiler itself working there just yet, so fixes like this can come later if absolutely necessary. Same with the changes to run-make as I believe run-make isn't run for target-only targets (as opposed to host+target targets).

I continue to be very wary of landing all these changes as it's quite a deal of difficult logic that isn't tested in any way, so I prefer to minimize the impact as much as possible.

@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Aug 25, 2015

Contributor

@alexcrichton They were due to variable expansions happening before llvm-config was built (ie not an issue if make all is run before tidy or check, thus I never caught it locally). Anyway, fixed.

Contributor

DiamondLovesYou commented Aug 25, 2015

@alexcrichton They were due to variable expansions happening before llvm-config was built (ie not an issue if make all is run before tidy or check, thus I never caught it locally). Anyway, fixed.

DiamondLovesYou added a commit to DiamondLovesYou/rust that referenced this pull request Aug 26, 2015

Make the fulldeps modes independent of their respective non-fulldeps …
…mode.

This is a change needed for #27937, so that `-L $(llvm-config --libdir)` is only
added to RUSTFLAGS for fulldeps based compiletest modes.
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 27, 2015

Contributor

Looks like good cleanup. I agree that the additional complexity in compiletest is unwarranted for now. Maybe we can fix this problem some other way and I'm happy to ignore all fulldeps tests on the web for a while.

Contributor

brson commented Aug 27, 2015

Looks like good cleanup. I agree that the additional complexity in compiletest is unwarranted for now. Maybe we can fix this problem some other way and I'm happy to ignore all fulldeps tests on the web for a while.

@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Sep 9, 2015

Contributor

@brson I'm not sure I understand what you mean by "I'm happy to ignore all fulldeps tests on the web for a while". Could you explain exactly what you mean?

Also, surely the benefit of the fulldep tests outweighs the pretty minimal additional complexity in compiletest (from calling llvm-config)? I mean I have no problem just disabling the fulldeps if that's way you'd like to go. I can file an issue and then comment out the fulldep test modes in tests.mk (assuming this is what you meant from above).

Contributor

DiamondLovesYou commented Sep 9, 2015

@brson I'm not sure I understand what you mean by "I'm happy to ignore all fulldeps tests on the web for a while". Could you explain exactly what you mean?

Also, surely the benefit of the fulldep tests outweighs the pretty minimal additional complexity in compiletest (from calling llvm-config)? I mean I have no problem just disabling the fulldeps if that's way you'd like to go. I can file an issue and then comment out the fulldep test modes in tests.mk (assuming this is what you meant from above).

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Sep 9, 2015

Member

Currently running the fulldeps tests means that the entire compiler has to be built for the target platform, and in this case that probably isn't necessary. I believe @brson means that in the interest of keeping this minimal (e.g. only running the run-pass tests for things like PNaCl) the changes to compiletest shouldn't be necessary because none of those link to LLVM.

Unfortunately "minimal complexity" ends up being bitrotted very quickly without being exercised which ends up porting it forward for a few years or so only to be painfully deleted at some point.

Member

alexcrichton commented Sep 9, 2015

Currently running the fulldeps tests means that the entire compiler has to be built for the target platform, and in this case that probably isn't necessary. I believe @brson means that in the interest of keeping this minimal (e.g. only running the run-pass tests for things like PNaCl) the changes to compiletest shouldn't be necessary because none of those link to LLVM.

Unfortunately "minimal complexity" ends up being bitrotted very quickly without being exercised which ends up porting it forward for a few years or so only to be painfully deleted at some point.

@wthrowe

This comment has been minimized.

Show comment
Hide comment
@wthrowe

wthrowe Sep 10, 2015

Contributor

Following up on some discussion on #28327: The current patch does not work for my use case, and I don't think the LLVM patch mentioned in the #28327 discussion is going to help, because I don't have a libLLVM.so or libLLVM-${VERSION}.so, so the current llvm-config logic will still apply. My system has all of the individual LLVM libraries installed as separate shared objects, so llvm-config is correctly reporting a long list of linker arguments for shared libraries.

Contributor

wthrowe commented Sep 10, 2015

Following up on some discussion on #28327: The current patch does not work for my use case, and I don't think the LLVM patch mentioned in the #28327 discussion is going to help, because I don't have a libLLVM.so or libLLVM-${VERSION}.so, so the current llvm-config logic will still apply. My system has all of the individual LLVM libraries installed as separate shared objects, so llvm-config is correctly reporting a long list of linker arguments for shared libraries.

@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Sep 10, 2015

Contributor

Is your system's LLVM built with CMake && BUILD_SHARED_LIBS ON? CMake
will build separate shared objects for each component in that case.

I'll have to add an extra flag to llvm-config to fix that.

On Thu, Sep 10, 2015 at 12:14 PM, wthrowe notifications@github.com wrote:

Following up on some discussion on #28327
#28327: The current patch does
not work for my use case, and I don't think the LLVM patch mentioned in the
#28327 #28327 discussion is going
to help, because I don't have a libLLVM.so or libLLVM-${VERSION}.so, so
the current llvm-config logic will still apply. My system has all of the
individual LLVM libraries installed as separate shared objects, so
llvm-config is correctly reporting a long list of linker arguments for
shared libraries.


Reply to this email directly or view it on GitHub
#27937 (comment).

Contributor

DiamondLovesYou commented Sep 10, 2015

Is your system's LLVM built with CMake && BUILD_SHARED_LIBS ON? CMake
will build separate shared objects for each component in that case.

I'll have to add an extra flag to llvm-config to fix that.

On Thu, Sep 10, 2015 at 12:14 PM, wthrowe notifications@github.com wrote:

Following up on some discussion on #28327
#28327: The current patch does
not work for my use case, and I don't think the LLVM patch mentioned in the
#28327 #28327 discussion is going
to help, because I don't have a libLLVM.so or libLLVM-${VERSION}.so, so
the current llvm-config logic will still apply. My system has all of the
individual LLVM libraries installed as separate shared objects, so
llvm-config is correctly reporting a long list of linker arguments for
shared libraries.


Reply to this email directly or view it on GitHub
#27937 (comment).

@wthrowe

This comment has been minimized.

Show comment
Hide comment
@wthrowe

wthrowe Sep 10, 2015

Contributor

Yes, it looks like it uses CMake with -DBUILD_SHARED_LIBS=ON. (This is Gentoo's official llvm-3.7.0 package.)

Contributor

wthrowe commented Sep 10, 2015

Yes, it looks like it uses CMake with -DBUILD_SHARED_LIBS=ON. (This is Gentoo's official llvm-3.7.0 package.)

@tomaka tomaka referenced this pull request in rust-lang/rfcs Sep 15, 2015

Closed

Make Rust work with emscripten #604

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 17, 2015

Contributor

☔️ The latest upstream changes (presumably #28421) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Sep 17, 2015

☔️ The latest upstream changes (presumably #28421) made this pull request unmergeable. Please resolve the merge conflicts.

@jauhien

This comment has been minimized.

Show comment
Hide comment
@jauhien

jauhien Sep 21, 2015

Contributor

Just fyi: we in Gentoo are interested in the possibility to link Rust to separated LLVM shared libraries, otherwise we can't use the system wide LLVM which is quite sad from the point of view of the overall build time.

Contributor

jauhien commented Sep 21, 2015

Just fyi: we in Gentoo are interested in the possibility to link Rust to separated LLVM shared libraries, otherwise we can't use the system wide LLVM which is quite sad from the point of view of the overall build time.

jauhien added a commit to jauhien/gentoo-rust that referenced this pull request Sep 23, 2015

[dev-lang/rust] version bump
LLVM in Gentoo is shipped as static libs only now,
until Rust upstream fixies linking using system wide LLVM is impossible
see rust-lang/rust#27937

-Werror during Rust building was disabled
@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Sep 27, 2015

Contributor

@jauhien I've just created this patch. It fixes llvm-config for cmake && BUILD_SHARED_LIBS.

Contributor

DiamondLovesYou commented Sep 27, 2015

@jauhien I've just created this patch. It fixes llvm-config for cmake && BUILD_SHARED_LIBS.

@brson brson referenced this pull request Nov 4, 2015

Closed

Dynamic LLVM #29558

@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Nov 15, 2015

Contributor

My patch has landed into LLVM proper and I've removed the extra stuff in compiletest w.r.t. fulldeps tests. This is ready to be merged.

Contributor

DiamondLovesYou commented Nov 15, 2015

My patch has landed into LLVM proper and I've removed the extra stuff in compiletest w.r.t. fulldeps tests. This is ready to be merged.

mk/llvm.mk
@@ -95,6 +95,8 @@ $(foreach host,$(CFG_HOST), \
# This can't be done in target.mk because it's included before this file.
define LLVM_LINKAGE_DEPS
$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.rustc_llvm: $$(LLVM_LINKAGE_PATH_$(2))
+RUSTFLAGS$(1)_rustc_llvm_T_$(3) += $$(shell $$(LLVM_CONFIG_$(3)) --components | tr '-' '_' |\

This comment has been minimized.

@alexcrichton

alexcrichton Nov 16, 2015

Member

Can this use $(LLVM_COMPONENTS) instead of re-invoking llvm-config here?

@alexcrichton

alexcrichton Nov 16, 2015

Member

Can this use $(LLVM_COMPONENTS) instead of re-invoking llvm-config here?

This comment has been minimized.

@alexcrichton

alexcrichton Nov 16, 2015

Member

This also seems to disagree currently in terms of which llvm-config is run?

@alexcrichton

alexcrichton Nov 16, 2015

Member

This also seems to disagree currently in terms of which llvm-config is run?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Nov 17, 2015

Contributor

Can this use $(LLVM_COMPONENTS) instead of re-invoking llvm-config here?

I don't see why not.

This also seems to disagree currently in terms of which llvm-config is run?

What do you mean?

@DiamondLovesYou

DiamondLovesYou Nov 17, 2015

Contributor

Can this use $(LLVM_COMPONENTS) instead of re-invoking llvm-config here?

I don't see why not.

This also seems to disagree currently in terms of which llvm-config is run?

What do you mean?

@@ -1732,6 +1738,7 @@ putvar CFG_AARCH64_LINUX_ANDROID_NDK
putvar CFG_ARM_LINUX_ANDROIDEABI_NDK
putvar CFG_I686_LINUX_ANDROID_NDK
putvar CFG_MANDIR
+putvar CFG_USING_LIBCPP

This comment has been minimized.

@alexcrichton

alexcrichton Nov 16, 2015

Member

Were these changes necessary for now? It looks like they're not needed elsewhere

@alexcrichton

alexcrichton Nov 16, 2015

Member

Were these changes necessary for now? It looks like they're not needed elsewhere

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Nov 17, 2015

Contributor

They should be needed in src/etc/mklldeps.py...

Huh. Somehow, that part of mklldeps didn't make it. I'll get that fixed.

@DiamondLovesYou

DiamondLovesYou Nov 17, 2015

Contributor

They should be needed in src/etc/mklldeps.py...

Huh. Somehow, that part of mklldeps didn't make it. I'll get that fixed.

mk/main.mk
LD_LIBRARY_PATH_ENV_TARGETDIR$(1)_T_$(2)_H_$(3) := \
- $$(CURDIR)/$$(TLIB1_T_$(2)_H_$(CFG_BUILD))
+ $$(CURDIR)/$$(TLIB1_T_$(2)_H_$(CFG_BUILD)):$$(CFG_LLVM_INST_DIR_$(CFG_BUILD))/lib

This comment has been minimized.

@alexcrichton

alexcrichton Nov 16, 2015

Member

I don't think that this belongs in the targetdir var because this is only needed for the compiler itself to run

@alexcrichton

alexcrichton Nov 16, 2015

Member

I don't think that this belongs in the targetdir var because this is only needed for the compiler itself to run

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Nov 23, 2015

Contributor

Fixed.

@DiamondLovesYou

DiamondLovesYou Nov 23, 2015

Contributor

Fixed.

@@ -53,6 +53,8 @@ def convert_path_spec(name, value):
putenv('TARGET_RPATH_DIR', os.path.abspath(sys.argv[11]))
putenv('RUST_BUILD_STAGE', sys.argv[12])
putenv('S', os.path.abspath(sys.argv[13]))
+putenv('RUSTFLAGS', sys.argv[15])

This comment has been minimized.

@alexcrichton

alexcrichton Nov 16, 2015

Member

Was this necessary to pass along? It looks like this isn't used elsewhere from this patch? Also this looks like it skipped a number?

@alexcrichton

alexcrichton Nov 16, 2015

Member

Was this necessary to pass along? It looks like this isn't used elsewhere from this patch? Also this looks like it skipped a number?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Nov 17, 2015

Contributor

Was this necessary to pass along? It looks like this isn't used elsewhere from this patch?

Yeah, the execution-engine test needs access to LLVM's dylib. Since trying to disable that test only when LLVM is shared would also require an additional env var, might as well just fix the test.

Also this looks like it skipped a number?

Didn't skip a number; target_triple from earlier in the file takes arguement 14.

@DiamondLovesYou

DiamondLovesYou Nov 17, 2015

Contributor

Was this necessary to pass along? It looks like this isn't used elsewhere from this patch?

Yeah, the execution-engine test needs access to LLVM's dylib. Since trying to disable that test only when LLVM is shared would also require an additional env var, might as well just fix the test.

Also this looks like it skipped a number?

Didn't skip a number; target_triple from earlier in the file takes arguement 14.

This comment has been minimized.

@alexcrichton

alexcrichton Nov 18, 2015

Member

Hm does the run-make test need to be updated to read this variable? It looks like there aren't changes to that?

@alexcrichton

alexcrichton Nov 18, 2015

Member

Hm does the run-make test need to be updated to read this variable? It looks like there aren't changes to that?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Nov 23, 2015

Contributor

Indeed, fixed.

@DiamondLovesYou

DiamondLovesYou Nov 23, 2015

Contributor

Indeed, fixed.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Nov 17, 2015

Contributor

☔️ The latest upstream changes (presumably #29794) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Nov 17, 2015

☔️ The latest upstream changes (presumably #29794) made this pull request unmergeable. Please resolve the merge conflicts.

@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Nov 24, 2015

Contributor

Ready to go.

Contributor

DiamondLovesYou commented Nov 24, 2015

Ready to go.

mk/llvm.mk
- $$(LLVM_CONFIG_$(1)) "$(CFG_STDCPP_NAME)"
+ $(Q)$(CFG_PYTHON) "$$<" "$$@" "$(filter $(shell \
+ $(CFG_LLVM_ROOT)/bin/llvm-config$(X_$(CFG_BUILD)) \
+ --components), \

This comment has been minimized.

@alexcrichton

alexcrichton Nov 30, 2015

Member

Can this be replaced with a variable defined below to avoid re-invoking llvm-config?

@alexcrichton

alexcrichton Nov 30, 2015

Member

Can this be replaced with a variable defined below to avoid re-invoking llvm-config?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Dec 3, 2015

Contributor

No, because we don't want to link unused LLVM components into rustc.

@DiamondLovesYou

DiamondLovesYou Dec 3, 2015

Contributor

No, because we don't want to link unused LLVM components into rustc.

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Dec 3, 2015

Contributor

I mean, I don't have a problem with just linking everything, I just thought you guys might not like it.

@DiamondLovesYou

DiamondLovesYou Dec 3, 2015

Contributor

I mean, I don't have a problem with just linking everything, I just thought you guys might not like it.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 30, 2015

Member

I have a feeling that this is likely to break over time (as there's no CI and this looks pretty brittle as so many build system things are), but it seems fine as it should be easy to get back up to speed in the future.

Member

alexcrichton commented Nov 30, 2015

I have a feeling that this is likely to break over time (as there's no CI and this looks pretty brittle as so many build system things are), but it seems fine as it should be easy to get back up to speed in the future.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 2, 2015

Contributor

☔️ The latest upstream changes (presumably #30157) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Dec 2, 2015

☔️ The latest upstream changes (presumably #30157) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 11, 2015

Member

Ok, the point about re-invoking llvm-config sounds good to me, can these commits be squashed into one as well? Other than that r=me

Member

alexcrichton commented Dec 11, 2015

Ok, the point about re-invoking llvm-config sounds good to me, can these commits be squashed into one as well? Other than that r=me

@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Dec 13, 2015

Contributor

Done!

Contributor

DiamondLovesYou commented Dec 13, 2015

Done!

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
Member

alexcrichton commented Dec 13, 2015

bors added a commit that referenced this pull request Dec 13, 2015

Auto merge of #27937 - DiamondLovesYou:llvm-root-and-shared, r=alexcr…
…ichton

This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 13, 2015

Contributor

⌛️ Testing commit abc6e7a with merge 3b5e8bf...

Contributor

bors commented Dec 13, 2015

⌛️ Testing commit abc6e7a with merge 3b5e8bf...

bors added a commit that referenced this pull request Dec 13, 2015

Auto merge of #27937 - DiamondLovesYou:llvm-root-and-shared, r=alexcr…
…ichton

This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 13, 2015

Contributor

💔 Test failed - auto-mac-64-nopt-t

Contributor

bors commented Dec 13, 2015

💔 Test failed - auto-mac-64-nopt-t

Better support for `--llvm-root`.
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
@DiamondLovesYou

This comment has been minimized.

Show comment
Hide comment
@DiamondLovesYou

DiamondLovesYou Dec 13, 2015

Contributor

Whoops, I forgot to push a change to llvm.mk.

Contributor

DiamondLovesYou commented Dec 13, 2015

Whoops, I forgot to push a change to llvm.mk.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
Member

alexcrichton commented Dec 14, 2015

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 14, 2015

Contributor

⌛️ Testing commit 7bd69f2 with merge f150c17...

Contributor

bors commented Dec 14, 2015

⌛️ Testing commit 7bd69f2 with merge f150c17...

bors added a commit that referenced this pull request Dec 14, 2015

Auto merge of #27937 - DiamondLovesYou:llvm-root-and-shared, r=alexcr…
…ichton

This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).

@bors bors merged commit 7bd69f2 into rust-lang:master Dec 14, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Dec 16, 2015

mk: Use the right llvmdeps.rs file for cross build
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm

bors added a commit that referenced this pull request Dec 18, 2015

Auto merge of #30414 - alexcrichton:fix-cross-builds, r=brson
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm

ubsan added a commit to ubsan/rust that referenced this pull request Dec 22, 2015

mk: Use the right llvmdeps.rs file for cross build
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm

fhahn added a commit to fhahn/rust that referenced this pull request Dec 28, 2015

mk: Use the right llvmdeps.rs file for cross build
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm

vivo75 added a commit to vivo75/vivovl that referenced this pull request Sep 6, 2017

[dev-lang/rust] version bump
LLVM in Gentoo is shipped as static libs only now,
until Rust upstream fixies linking using system wide LLVM is impossible
see rust-lang/rust#27937

-Werror during Rust building was disabled
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment