Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

__error() not provided for x86_64-unknown-dragonfly #1627

Closed
tuxillo opened this issue Dec 17, 2019 · 7 comments
Closed

__error() not provided for x86_64-unknown-dragonfly #1627

tuxillo opened this issue Dec 17, 2019 · 7 comments
Labels
C-API-request Category: API request O-dragonfly

Comments

@tuxillo
Copy link

tuxillo commented Dec 17, 2019

  • Target: x86_64-unknown-dragonfly (not in the CI)
  • Instructions to reproduce: just try to build in this platform

After commit 3fa021d, libc won't provide __error() for DragonFly. We've spotted this by trying to build rust-1.39, which includes a newer libc crate (0.2.62) that contains this change.

The error shows up when the build tries to make use of libc::__error():

error[E0432]: unresolved import `libc::__error`
  --> /usr/obj/dports/lang/rust.139/rustc-1.39.0-src/vendor/getrandom/src/util_libc.rs:22:13
   |
22 |         use libc::__error as errno_location;
   |             ^^^^^^-------^^^^^^^^^^^^^^^^^^
   |             |     |
   |             |     help: a similar name exists in the module: `ferror`
   |             no `__error` in the root

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: Could not compile `getrandom`.
warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/usr/obj/dports/lang/rust.139/rustc-1.39.0-src/build/x86_64-unknown-dragonfly/stage0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-dragonfly" "-Zbinary-de
p-depinfo" "-j" "24" "--release" "--frozen" "--features" "" "--manifest-path" "/usr/obj/dports/lang/rust.139/rustc-1.39.0-src/src/rustc/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
Traceback (most recent call last):
  File "/usr/obj/dports/lang/rust.139/rustc-1.39.0-src/x.py", line 11, in <module>
    bootstrap.main()
  File "/usr/obj/dports/lang/rust.139/rustc-1.39.0-src/src/bootstrap/bootstrap.py", line 913, in main
    bootstrap(help_triggered)
  File "/usr/obj/dports/lang/rust.139/rustc-1.39.0-src/src/bootstrap/bootstrap.py", line 899, in bootstrap
    run(args, env=env, verbose=build.verbose)
  File "/usr/obj/dports/lang/rust.139/rustc-1.39.0-src/src/bootstrap/bootstrap.py", line 141, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /usr/obj/dports/lang/rust.139/rustc-1.39.0-src/build/bootstrap/debug/bootstrap build --verbose --config ./config.toml --jobs 24
*** Error code 1

Stop.
make[1]: stopped in /usr/dports/lang/rust.139
*** Error code 1

Stop.

Let me know if you need additional information and I'll provide it.

@tuxillo tuxillo changed the title Build broken for x86_64-unknown-dragonfly __error() not provided for x86_64-unknown-dragonfly Dec 17, 2019
@gnzlbg
Copy link
Contributor

gnzlbg commented Dec 23, 2019

AFAICT the __error function is still available on DragonflyBSD. It was previously only provided if cfg!(libc_thread_local) is true, and that remains to be the case. cc @josephlr

@tuxillo
Copy link
Author

tuxillo commented Dec 24, 2019

As far as I can tell, even removing the conditional so that the feature is always enabled is not enough for this to build.

I changed:

#![cfg_attr(libc_thread_local, feature(thread_local))]

to

#![feature(thread_local)]

Maybe I'm missing something?

@josephlr
Copy link
Contributor

Sorry about missing this, it slipped by me over the holidays. #1432 added __error for DragonflyBSD, but only when the libc crate is a dependency of libstd. The reasoning is here: #1432 (comment) Essentially, getting DragonflyBSD errno to work requires nightly, but all the crates that would use this feature don't want to require nightly.

The reason you're hitting this issue is my fault however, see rust-random/getrandom#124. This was fixed in rust-random/getrandom#129 , which was released with getrandom 0.1.14.

Regardless, I think this issue can be closed.

@tuxillo
Copy link
Author

tuxillo commented Feb 26, 2020

Thanks for the info. Please hold this off a bit, we're about to release 5.8 which has __errno_location, and in that case we can fall into the linux case, see this: https://github.com/DragonFlyBSD/DeltaPorts/blob/master/ports/games/veloren/dragonfly/patch-util_libc.rs

@tuxillo
Copy link
Author

tuxillo commented Mar 21, 2020

We have now released 5.8 which contains __errno_location

@tuxillo
Copy link
Author

tuxillo commented May 22, 2020

See this commit, its now provided from libc in both stable and head releases:
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/60d311380ff2bf02a87700a0f3e6eb53e6034920

commit 60d311380ff2bf02a87700a0f3e6eb53e6034920
Author: zrj <rimvydas.jasinskas@gmail.com>
Date:   Sat Oct 5 13:04:12 2019 +0300

    libc: Add __errno_location() for language binding benefits.
    
     Some languages have restrictions when it comes to C style TLS handling
     (thread local might be feature-gated) or simply it is inconvenient to
     add various OS specific binding wrappers just to access C errno values.
    
     The __errno_location() symbol provides externally callable version of
     __error() inline function.
    
     While there, add __WANT_NO_INLINED___ERROR guard for few python parsers
     in DPorts that are unable to parse inlined __error() code yet.

It coud be exported in src/unix/bsd/freebsdlike/dragonfly/mod.rs via extern C, which is what we do for fixing Rust packages.

@JohnTitor JohnTitor added C-API-request Category: API request O-dragonfly labels Oct 15, 2020
@JohnTitor
Copy link
Member

Fixed by #1875.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-API-request Category: API request O-dragonfly
Projects
None yet
Development

No branches or pull requests

4 participants