Deny mixing bin crate type with lib crate types

[bjorn3]

The produced library would get a main shim too which conflicts with the
main shim of the executable linking the library.

$ cat > main1.rs <<EOF
fn main() {}
pub fn bar() {}
EOF
$ cat > main2.rs <<EOF
extern crate main1;
fn main() {
    main1::bar();
}
EOF
$ rustc --crate-type bin --crate-type lib main1.rs
$ rustc -L. main2.rs
error: linking with `cc` failed: exit status: 1
[...]
  = note: /usr/bin/ld: /tmp/crate_bin_lib/libmain1.rlib(main1.main1.707747aa-cgu.0.rcgu.o): in function `main':
          main1.707747aa-cgu.0:(.text.main+0x0): multiple definition of `main'; main2.main2.02a148fe-cgu.0.rcgu.o:main2.02a148fe-cgu.0:(.text.main+0x0): first defined here
          collect2: error: ld returned 1 exit status

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[estebank]

@bors r+

[bors]

📌 Commit 0b59630 has been approved by estebank

[gheoan]

In the past, I have emited both a dylib and a bin from the same file with the crate-type option. The binary was dynamically loading the dylib without problems, on both the windows-msvc and linux-gnu targets. However, I am not familiar with the semantics of the dynamic loader regarding conflicting symbols.

It would be great if this PR could be reconsidered, at least for mixing dylib and bin. I suggest issuing a warning instead of a hard error or somehow stripping the main symbol(s) from the libs using something like #20267.

There are workaround to this PR, however I am wondering if compiling a mixed file is faster then invoking the compiler twice, once for each crate type. If someone familiar with the internals of the compiler has a perspective on this, let me know.

[bjorn3]

In the past, I have emited both a dylib and a bin from the same file with the crate-type option. The binary was dynamically loading the dylib without problems

Why did you exactly do it that way? Why not have a separate bin and dylib target with each just the code you need Also you would end up with two copies of libstd in the same process which is UB as things like the panic state would end up being duplicated which may result in eg double panics not being detected.

[SoniEx2]

maybe you're making an ld.so?

$ /usr/lib/ld-linux-x86-64.so.2 --help
Usage: /usr/lib/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs.  Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.

You may invoke the program interpreter program directly from the command
line to load and run an ELF executable file; this is like executing that
file itself, but always uses the program interpreter you invoked,
instead of the program interpreter specified in the executable file you
run.  Invoking the program interpreter directly provides access to
additional diagnostics, and changing the dynamic linker behavior without
setting environment variables (which would be inherited by subprocesses).

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache       Do not use /etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --glibc-hwcaps-prepend LIST
                        search glibc-hwcaps subdirectories in LIST
  --glibc-hwcaps-mask LIST
                        only search built-in subdirectories if in LIST
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST          use objects named in LIST as auditors
  --preload LIST        preload objects named in LIST
  --argv0 STRING        set argv[0] to STRING before running
  --list-tunables       list all tunables with minimum and maximum values
  --list-diagnostics    list diagnostics information
  --help                display this help and exit
  --version             output version information and exit

This program interpreter self-identifies as: /usr/lib/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

Legacy HWCAP subdirectories under library search path directories:
  x86_64 (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  avx512_1
  x86_64 (supported, searched)

[estebank]

CC @rust-lang/compiler for discussion on thursday

[bjorn3]

maybe you're making an ld.so?

Specifying both crate types will not produce a single file that is both an executable and dylib as you seem to think. It will make an executable and a separate dylib neither of which is capable of satisfying the other role. For something like ld.so you should try a cdylib and then passing -Wl,-e,_dlstart as link argument (assuming your main function is called _dlstart). Or you can try a staticlib and link with -shared -Wl,-e,_dlstart. (for context: I ported part of musl's ld.so to rust. The last option is what I did.)