os::dll_filename() picks prefix of shared library based on host arch

[ILyoan]

back::link_binary() calls os::dll_filename() to get output library name
but os::dll_filename() picks prefix only depending on the host arch instead of target.
It should be based on the target arch

[brson]

Here is how I think we should solve this, at least in the short term: core::os has a module called consts that use conditional compilation to only define these constants for the host platform. Instead we can define them all, always, and use conditional compilation to make just one the default.

Instead of

#[cfg(target_os = "macos")]
mod consts {       
    pub fn sysname() -> ~str { ~"macos" }
    pub fn exe_suffix() -> ~str { ~"" }
    pub fn dll_suffix() -> ~str { ~".dylib" }
}           

This:

mod consts {

    #[cfg(target_os = "macos")]
    pub use macos::sysname;
    // etc.

    mod macos {
        pub fn sysname() -> ~str { ~"macos" }
        pub fn exe_suffix() -> ~str { ~"" }
        pub fn dll_suffix() -> ~str { ~".dylib" }
    }
}           

rustc would have to implement its own version of dll_filename that picked the correct submodule, but at least all the constants remain defined in one place.

There is also some code in rustc::metadata::loader that has it's own logic to do this. It should be converted.

[brson]

@graydon you might have an opinion on this

[brson]

@ILyoan on IRC yesterday you had some other ideas about how to fix this. Have you come up with a solution that works for you? If not, do you want me to implement something like I described above?

[ILyoan]

@brson Oh! is it too late to answer?
I cound't find a way to change target_os configuration during compiling the libcore for the target.
When compile the libcore for target, since rustc uses the host libcore which has already been configured as host (#[cfg(target_os='<host_os>')]) so it returns dll_name for host I guess.
I'm not sure if i could deal with it so I would be glad if you would handle this.

[ILyoan]

@brson "rustc would have to implement its own version of dll_filename that picked the correct submodule, but at least all the constants remain defined in one place."

sorry I had missed the sentence :(

I think I can handle it with that approach.