Discussion:
rust broken?
(too old to reply)
Michael Butler
2018-06-07 15:44:53 UTC
Permalink
In response to a Firefox update, I tried to build the new version.
However, rust now fails with a core-dump in the build process.

checking for libffi > 3.0.9... yes
checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
checking for rustc... /usr/local/bin/rustc
checking for cargo... /usr/local/bin/cargo
checking rustc version...
DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
DEBUG: The command returned non-zero exit status -12.
DEBUG: Its output was:
DEBUG: | rustc 1.26.0
DEBUG: | binary: rustc
DEBUG: | commit-hash: unknown
DEBUG: | commit-date: unknown
DEBUG: | host: x86_64-unknown-freebsd
DEBUG: | release: 1.26.0
ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
exit status -12.

Attempts to rebuild rust (and cargo) from the bootstrap files fail in
similar fashion.

On a machine running a SVN r334538 kernel but more recent user-land, it
builds successfully. With (the only difference being) a kernel at SVN
r334748, it does not.

Any hints/thoughts?

imb
Alan Somers
2018-06-07 17:11:05 UTC
Permalink
Can you reproduce the problem using rust installed from rustup instead of
from Ports? If so, you should file a bug report with the Rust developers.
Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
1.26.0.
-Alan
Post by Michael Butler
In response to a Firefox update, I tried to build the new version.
However, rust now fails with a core-dump in the build process.
checking for libffi > 3.0.9... yes
checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
checking for rustc... /usr/local/bin/rustc
checking for cargo... /usr/local/bin/cargo
checking rustc version...
DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
DEBUG: The command returned non-zero exit status -12.
DEBUG: | rustc 1.26.0
DEBUG: | binary: rustc
DEBUG: | commit-hash: unknown
DEBUG: | commit-date: unknown
DEBUG: | host: x86_64-unknown-freebsd
DEBUG: | release: 1.26.0
ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
exit status -12.
Attempts to rebuild rust (and cargo) from the bootstrap files fail in
similar fashion.
On a machine running a SVN r334538 kernel but more recent user-land, it
builds successfully. With (the only difference being) a kernel at SVN
r334748, it does not.
Any hints/thoughts?
imb
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
Michael Butler
2018-06-07 17:33:22 UTC
Permalink
Ah - I'll re-enable that to see if it makes a difference ..

I missed that in the comparison between my two build environments :-(

Michael
Rustup uses the 11 ABI.
Can you reproduce the problem using rust installed from rustup instead of
from Ports?  If so, you should file a bug report with the Rust
developers.
Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
1.26.0.
-Alan
On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler
Post by Michael Butler
In response to a Firefox update, I tried to build the new version.
However, rust now fails with a core-dump in the build process.
checking for libffi > 3.0.9... yes
checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
checking for rustc... /usr/local/bin/rustc
checking for cargo... /usr/local/bin/cargo
checking rustc version...
DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
DEBUG: The command returned non-zero exit status -12.
DEBUG: | rustc 1.26.0
DEBUG: | binary: rustc
DEBUG: | commit-hash: unknown
DEBUG: | commit-date: unknown
DEBUG: | host: x86_64-unknown-freebsd
DEBUG: | release: 1.26.0
ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
exit status -12.
Attempts to rebuild rust (and cargo) from the bootstrap files fail in
similar fashion.
On a machine running a SVN r334538 kernel but more recent
user-land, it
Post by Michael Butler
builds successfully. With (the only difference being) a kernel at SVN
r334748, it does not.
Any hints/thoughts?
         imb
_______________________________________________
mailing list
Post by Michael Butler
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
_______________________________________________
mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Michael Butler
2018-06-07 17:50:25 UTC
Permalink
Post by Michael Butler
Ah - I'll re-enable that to see if it makes a difference ..
It's not a question of enabling. It doesn't explicitly use the 11
symbols. Rust developers assume that every OS has a frozen ABI like
Linux. The rust from rustup will only work on 11. This is why you need
to use the port / pkg.
I commented out this line in my kernel config ..

nooption COMPAT_FREEBSD11

.. and the port's bootstrap files now run as they should :-)

Sorry for the noise - self-inflicted wound :-(

imb
Matthew Macy
2018-06-07 17:52:20 UTC
Permalink
Post by Michael Butler
Post by Michael Butler
Ah - I'll re-enable that to see if it makes a difference ..
It's not a question of enabling. It doesn't explicitly use the 11
symbols. Rust developers assume that every OS has a frozen ABI like
Linux. The rust from rustup will only work on 11. This is why you need
to use the port / pkg.
I commented out this line in my kernel config ..
nooption COMPAT_FREEBSD11
Ah. Yes. The port uses the 11 ABI symbols explicitly.
Post by Michael Butler
.. and the port's bootstrap files now run as they should :-)
Sorry for the noise - self-inflicted wound :-(
imb
Matthew Macy
2018-06-07 17:36:24 UTC
Permalink
Post by Michael Butler
Ah - I'll re-enable that to see if it makes a difference ..
It's not a question of enabling. It doesn't explicitly use the 11 symbols.
Rust developers assume that every OS has a frozen ABI like Linux. The rust
from rustup will only work on 11. This is why you need to use the port /
pkg.

-M
Post by Michael Butler
I missed that in the comparison between my two build environments :-(
Michael
Rustup uses the 11 ABI.
Can you reproduce the problem using rust installed from rustup instead of
from Ports? If so, you should file a bug report with the Rust developers.
Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
1.26.0.
-Alan
On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler
Post by Michael Butler
In response to a Firefox update, I tried to build the new version.
However, rust now fails with a core-dump in the build process.
checking for libffi > 3.0.9... yes
checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
checking for rustc... /usr/local/bin/rustc
checking for cargo... /usr/local/bin/cargo
checking rustc version...
DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
DEBUG: The command returned non-zero exit status -12.
DEBUG: | rustc 1.26.0
DEBUG: | binary: rustc
DEBUG: | commit-hash: unknown
DEBUG: | commit-date: unknown
DEBUG: | host: x86_64-unknown-freebsd
DEBUG: | release: 1.26.0
ERROR: Command `/usr/local/bin/rustc --version --verbose` failed
with
Post by Michael Butler
exit status -12.
Attempts to rebuild rust (and cargo) from the bootstrap files fail
in
Post by Michael Butler
similar fashion.
On a machine running a SVN r334538 kernel but more recent
user-land, it
Post by Michael Butler
builds successfully. With (the only difference being) a kernel at
SVN
Post by Michael Butler
r334748, it does not.
Any hints/thoughts?
imb
_______________________________________________
mailing list
Post by Michael Butler
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
_______________________________________________
mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Greg
2018-06-08 06:26:35 UTC
Permalink
Post by Matthew Macy
Post by Michael Butler
Ah - I'll re-enable that to see if it makes a difference ..
It's not a question of enabling. It doesn't explicitly use the 11 symbols.
Rust developers assume that every OS has a frozen ABI like Linux. The rust
from rustup will only work on 11. This is why you need to use the port /
pkg.
It does use the 11 (pre-ino64) symbols.
Rust from rustup has worked fine on CURRENT for a few months already.
K. Macy
2018-06-08 16:27:06 UTC
Permalink
Post by Greg
Post by Matthew Macy
Post by Michael Butler
Ah - I'll re-enable that to see if it makes a difference ..
It's not a question of enabling. It doesn't explicitly use the 11 symbols.
Rust developers assume that every OS has a frozen ABI like Linux. The rust
from rustup will only work on 11. This is why you need to use the port /
pkg.
It does use the 11 (pre-ino64) symbols.
Rust from rustup has worked fine on CURRENT for a few months already.
There's also kevent and who knows what else. But that's cool. There
was no sign of movement there when last I used Rust in October.

-M

Matthew Macy
2018-06-07 17:21:59 UTC
Permalink
Rustup uses the 11 ABI.
Post by Alan Somers
Can you reproduce the problem using rust installed from rustup instead of
from Ports? If so, you should file a bug report with the Rust developers.
Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
1.26.0.
-Alan
Post by Michael Butler
In response to a Firefox update, I tried to build the new version.
However, rust now fails with a core-dump in the build process.
checking for libffi > 3.0.9... yes
checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
checking for rustc... /usr/local/bin/rustc
checking for cargo... /usr/local/bin/cargo
checking rustc version...
DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
DEBUG: The command returned non-zero exit status -12.
DEBUG: | rustc 1.26.0
DEBUG: | binary: rustc
DEBUG: | commit-hash: unknown
DEBUG: | commit-date: unknown
DEBUG: | host: x86_64-unknown-freebsd
DEBUG: | release: 1.26.0
ERROR: Command `/usr/local/bin/rustc --version --verbose` failed with
exit status -12.
Attempts to rebuild rust (and cargo) from the bootstrap files fail in
similar fashion.
On a machine running a SVN r334538 kernel but more recent user-land, it
builds successfully. With (the only difference being) a kernel at SVN
r334748, it does not.
Any hints/thoughts?
imb
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
Loading...