[rust-dev] Issues linking a static Rust library

[Tahia Khan]

Hey all! Rust newbie here. I'm having some problems including a static Rust
library inside of an Objective-C project on XCode.

I was looking through rustc source code (specifically /back/link.rs) and I
saw that rlibs and staticlibs are built very similarly (in fact link_rlib
is called inside of link_staticlib). According to the comments above the
link_rlib function in link.rs, non-object "magical files" are tacked onto
the end of archive files for rlibs/staticlibs. I inspected my staticlib
with otool and confirmed that there are a bunch of non-object files at the
end:

libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-rand-rand-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-sync-sync-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-rustrt-rustrt-4e7c5e5c.0.bytecode.deflate): is not an object
file
libtreble.a(r-collections-collections-4e7c5e5c.0.bytecode.deflate): is not
an object file
libtreble.a(r-alloc-alloc-4e7c5e5c.0.bytecode.deflate): is not an object
file
libtreble.a(r-libc-libc-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-unicode-unicode-4e7c5e5c.0.bytecode.deflate): is not an
object file
libtreble.a(r-core-core-4e7c5e5c.0.bytecode.deflate): is not an object file

When I try to build my Xcode project, my build fails with the following
error:

ld: in
[path-to-library]/rust-from-c/libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate),
archive member 'r-std-std-4e7c5e5c.0.bytecode.deflate' with length 999896
is not mach-o or llvm bitcode for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

It looks like the Xcode linker hits the very first non-object file then
isn't able to determine the architecture of the archive. Does anyone know
if there's some way to exclude these non-object files in a staticlib/rlib?
Or if there's some other way to avoid this build issue with the XCode
linker?

Cheers,
Tahia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141007/afe35aa0/attachment.html>

[Ilya Dmitrichenko]

Sounds like very annoying sort of issue... Have you tried patching
this via a script or manually for the start?

ar x libtreble.a
ar c libtreble.a *.o

Also, the good question to ask how those non-traditional files in a
static library archive are use... I would assume that compilers other
then rustc would not be able to make any use of it whatsoever.

?
Ilya Dmitrichenko

Post by Tahia Khan
Hey all! Rust newbie here. I'm having some problems including a static Rust
library inside of an Objective-C project on XCode.
I was looking through rustc source code (specifically /back/link.rs) and I
saw that rlibs and staticlibs are built very similarly (in fact link_rlib is
called inside of link_staticlib). According to the comments above the
link_rlib function in link.rs, non-object "magical files" are tacked onto
the end of archive files for rlibs/staticlibs. I inspected my staticlib with
libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-rand-rand-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-sync-sync-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-rustrt-rustrt-4e7c5e5c.0.bytecode.deflate): is not an object
file
libtreble.a(r-collections-collections-4e7c5e5c.0.bytecode.deflate): is not
an object file
libtreble.a(r-alloc-alloc-4e7c5e5c.0.bytecode.deflate): is not an object
file
libtreble.a(r-libc-libc-4e7c5e5c.0.bytecode.deflate): is not an object file
libtreble.a(r-unicode-unicode-4e7c5e5c.0.bytecode.deflate): is not an object
file
libtreble.a(r-core-core-4e7c5e5c.0.bytecode.deflate): is not an object file
When I try to build my Xcode project, my build fails with the following
ld: in
[path-to-library]/rust-from-c/libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate),
archive member 'r-std-std-4e7c5e5c.0.bytecode.deflate' with length 999896 is
not mach-o or llvm bitcode for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
It looks like the Xcode linker hits the very first non-object file then
isn't able to determine the architecture of the archive. Does anyone know if
there's some way to exclude these non-object files in a staticlib/rlib? Or
if there's some other way to avoid this build issue with the XCode linker?
Cheers,
Tahia
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[comex]

Does anyone know if there's some way to exclude these non-object files in a
staticlib/rlib? Or if there's some other way to avoid this build issue with
the XCode linker?

Does Xcode's linker command line contain -force_load or -all_load? If
I'm reading the ld64 source code correctly, it'll only try to load all
the files as objects when those flags are set.

[Tahia Khan]

Thanks so much for the responses, they were very helpful! I ended up
manually working with the archive with ar commands (never knew about that
tool, thanks Ilya!) to get rid of non-object files and then suppressing
compiler errors about unresolved symbols (symbols that were specific to
rust I think, eg r-morestack-moretack.o) in the XCode linker with
"-undefined warning" flag. A bit hacky, but good enough for my purposes!

As for how these non-object files are used in static libraries.. from what
I can gather after researching the file types I encountered, looks like
they are used by LLVM for link time optimization.

Tahia

Post by comex

Does anyone know if there's some way to exclude these non-object files

in a

staticlib/rlib? Or if there's some other way to avoid this build issue

with

the XCode linker?

Does Xcode's linker command line contain -force_load or -all_load? If
I'm reading the ld64 source code correctly, it'll only try to load all
the files as objects when those flags are set.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141007/9d6e4f35/attachment.html>