On 11/18/2013 06:22 PM, Alex Crichton wrote:
* #[link(...)] becomes the new method of specifying linkage semantics on extern
blocks, and it may be used similarly to link_args today
I'd kind of like for this to be available at the crate level too since most
libraries don't use OS X two-level
On 11/18/2013 08:01 PM, Zack Corr wrote:
On Tue, Nov 19, 2013 at 11:13 AM, Brian Anderson
bander...@mozilla.com mailto:bander...@mozilla.com wrote:
Of course this conflicts with the `link` attribute of crates,
which I think is poorly named anyway.
Perhaps #[link] in its current usage
On 11/15/2013 12:09 AM, Alex Crichton wrote:
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic
On 11/15/2013 03:01 AM, Niko Matsakis wrote:
A few quick questions and comments:
On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote:
As a side node, after writing all this up, I remembered LTO as an
option for generating libraries. I don't think I know enough about LTO
to be able to
On 11/15/2013 03:01 AM, Niko Matsakis wrote:
A few quick questions and comments:
On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote:
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
* #[link(...)] becomes the new method of specifying linkage semantics on
extern
blocks, and it may be used similarly to link_args today
I'd kind of like for this to be available at the crate level too since most
libraries don't use OS X two-level namespaces and it's more convient to me
On Tue, Nov 19, 2013 at 11:13 AM, Brian Anderson bander...@mozilla.comwrote:
Of course this conflicts with the `link` attribute of crates, which I
think is poorly named anyway.
Perhaps #[link] in its current usage should be renamed to #[crate]? I think
that would make more sense.
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries.
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries. This
includes things like librustrt and libextra. Rust shouldn't be striving to
lift
dependence on system libraries, that'll come at later times
On Fri, Nov 15, 2013 at 12:28 PM, Alex Crichton a...@crichton.co wrote:
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries. This
includes things like librustrt and libextra. Rust shouldn't be striving
Hm, I suppose I should re-phrase. Rust's linkage model should not
attempt to lift dependence on global native libraries. These global
libraries (like libm and librt on linux) should be assumed to be
everywhere. Our result artifacts must always be linked against them
(if their functionality is
On Fri, Nov 15, 2013 at 09:28:49AM -0800, Alex Crichton wrote:
To this end, I mainly
point out that rust should roll in local native static libraries, and
just live with global native dynamic libraries.
How does rustc know the difference? Because the local native libraries
are tagged as
To this end, I mainly
point out that rust should roll in local native static libraries, and
just live with global native dynamic libraries.
How does rustc know the difference? Because the local native libraries
are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?)
You're
So in the case of --staticlib, if my Rust library, libmycomp.a, depended on
non-Rust local native library, libfoo.a, would Rust then bundle all modules
from libfoo into libmycomp? Or would it only do so for Rust libraries,
e.g. libstd.a?
On Fri, Nov 15, 2013 at 12:09 AM, Alex Crichton
You would be required to specify that the native library would be static via
#[link(name = foo, static)]
extern { ... }
And then rustc would bundle libfoo.a with libmycomp.a. libmycomp.a
would also include any upstream rust dependencies (libstd.a,
libextra.a, etc.)
On Fri, Nov 15, 2013 at 12:00
What if the final executable also wants to link against a slightly newer
version of libfoo.a? I'm not even sure what ld would do then. Complains
about duplicate symbols? Picks one at random?
I think I'd rather have Rust object file along with a list of libraries
that will be needed for final
16 matches
Mail list logo
