On 07/14/2016 05:15 PM, Simo Sorce wrote:
> Until the Rust ecosystem becomes more stable, it is better to upgrade
> it regularly than have a stale tool nobody can really use.
> There are even crates that work only with nightlies for now, so trying
> to stay on par is necessary to make it useful.
On Wed, 2016-07-13 at 12:42 -0700, Josh Stone wrote:
> On 07/13/2016 07:50 AM, Adam Jackson wrote:
> > On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote:
> > > Rust uses LLVM for codegen, so in theory, yes. This excludes any
> > > potential platform-specific bugs that may affect rustc, which
On 07/13/2016 07:50 AM, Adam Jackson wrote:
> On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote:
>> Rust uses LLVM for codegen, so in theory, yes. This excludes any
>> potential platform-specific bugs that may affect rustc, which are
>> certainly a possibility.
>
> At the moment llvm has
On Wed, 13 Jul 2016 09:02:06 -0700
Josh Stone wrote:
> On 07/12/2016 11:45 PM, Dan Horák wrote:
> > How does the new language (and compiler) affect secondary
> > architectures? Will it just work?
>
> Rust has their own tier system of architecture support:
>
>
On 07/13/2016 09:10 AM, Stefan Nuxoll wrote:
> ABI stability is entirely dependent on compiler version, AFAIK.
> Within the same version of rustc there should be no issues with
> dynamic linking,
I suspect that may true in general, but I don't think it's promised, and
I don't really trust it. We
On 07/12/2016 09:18 PM, Jan Kurik wrote:
> Rust 1.10.0 was released on July 7 along with Cargo 0.11.0. These will
> be the initial targets to package. Rust's next release is scheduled
> for August 18 on a 6-week cycle. Backwards compatibility is taken very
> seriously, so it should be possible to
ABI stability is entirely dependent on compiler version, AFAIK. Within the same
version of rustc there should be no issues with dynamic linking, of course
whenever we upgrade rustc we'd need a mass rebuild of every rust package but
we'd have to do the same thing with static linking.
--
devel
On 07/13/2016 02:24 AM, Dridi Boukelmoune wrote:
> Since 1.10 (the target of this change) it has become possible to
> create "cdylib" (C dynamic library) crates, basically shared objects
> that can be linked to by non-Rust programs.
>
> It isn't supported by cargo yet, but it's available..
Yes,
On 07/13/2016 12:29 AM, Stefan Nuxoll wrote:
> Rust supports dynamic linking, would it be worth investigating that
> route instead of copying the proposed Go guidelines? I'm not against
> static linking at all costs, but it would make package maintenance
> (especially security updates) a lot more
On 07/12/2016 11:45 PM, Dan Horák wrote:
> How does the new language (and compiler) affect secondary architectures?
> Will it just work?
Rust has their own tier system of architecture support:
https://doc.rust-lang.org/book/getting-started.html#platform-support
Only i686 and x86_64 are Tier 1
On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote:
> Rust uses LLVM for codegen, so in theory, yes. This excludes any
> potential platform-specific bugs that may affect rustc, which are
> certainly a possibility.
At the moment llvm has codegen support for every Fedora architecture,
primary
On Wed, Jul 13, 2016 at 11:11 AM, Igor Gnatenko wrote:
> I meant that rust itself links dynamically to system libraries. But
> libraries built by rust are not supposed to be dynamically linked by
> programs.
Hello,
Since 1.10 (the target of this change) it has become
I meant that rust itself links dynamically to system libraries. But
libraries built by rust are not supposed to be dynamically linked by
programs.
At least at this moment. So for now I don't see alternatives to have same
packaging guidelines as for Go.
-Igor Gnatenko
On Jul 13, 2016 11:05 AM,
On Wed, 13 Jul 2016, Igor Gnatenko wrote:
Currently it's not possible for dynamic linking...
Why?
Dynamic linking is supported by Rust and according to its documentation,
is enabled for system libraries on Linux by default.
Can you explain why you are claiming it is not possible to enable
Currently it's not possible for dynamic linking...
On Wed, Jul 13, 2016 at 9:29 AM, Stefan Nuxoll wrote:
> Rust supports dynamic linking, would it be worth investigating that route
> instead of copying the proposed Go guidelines? I'm not against static linking
> at all costs,
On Wed, Jul 13, 2016 at 8:45 AM, Dan Horák wrote:
> On Wed, 13 Jul 2016 06:18:17 +0200
> Jan Kurik wrote:
>
>> = Proposed Self Contained Change: Rust Compiler =
>> https://fedoraproject.org/wiki/Changes/RustCompiler
>>
>> Change owner(s):
>> * Josh Stone
>>
>>
Rust supports dynamic linking, would it be worth investigating that route
instead of copying the proposed Go guidelines? I'm not against static linking
at all costs, but it would make package maintenance (especially security
updates) a lot more pleasant.
--
devel mailing list
Rust uses LLVM for codegen, so in theory, yes. This excludes any potential
platform-specific bugs that may affect rustc, which are certainly a possibility.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Wed, 13 Jul 2016 06:18:17 +0200
Jan Kurik wrote:
> = Proposed Self Contained Change: Rust Compiler =
> https://fedoraproject.org/wiki/Changes/RustCompiler
>
> Change owner(s):
> * Josh Stone
>
> Introduce packages for the Rust compiler and its Cargo build system.
>
>
>
= Proposed Self Contained Change: Rust Compiler =
https://fedoraproject.org/wiki/Changes/RustCompiler
Change owner(s):
* Josh Stone
Introduce packages for the Rust compiler and its Cargo build system.
== Detailed Description ==
In the project's own words, "Rust is a systems programming
= Proposed Self Contained Change: Rust Compiler =
https://fedoraproject.org/wiki/Changes/RustCompiler
Change owner(s):
* Josh Stone
Introduce packages for the Rust compiler and its Cargo build system.
== Detailed Description ==
In the project's own words, "Rust is a systems programming
21 matches
Mail list logo