When I try to use mozjpeg-sys = "0.5.11" in the same project as jpeg-decoder = "0.1.14" I get:

    Updating registry `https://github.com/rust-lang/crates.io-index`
error: failed to select a version for `rayon-core` (required by `rayon`):
all possible versions conflict with previously selected versions of `rayon-core`
  version 1.3.0 in use by rayon-core v1.3.0
  possible versions to select: 1.4.0

Because jpeg-decoder depends on rayon 1.0 but mozjpeg-sys's build.rs depends on nasm-rs which depends on rayon 0.9

MSVC targets don't have "ar", but "lib" instead. lib unfortunately has different command-line arguments, so it can't be used as a drop in replacement for ar.

The version parser cannot handle the format of nasm RC builds (e.g. from nasm git)

  cargo:warning=This version of NASM is too old: NASM version 2.16rc0 compiled on Jan 10 2022
  . Required >= 2.14.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 nasm-rs Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @medek

Could you release the code from master?

The msvc target uses lib rather than ar to compose objects into static library.

It requires:

• cc crate, because it has a helper function necessary to find Visual Studio path, to locate lib.exe
• running lib.exe /out:*.lib *.o instead of ar crus

Would you be interested in PR for this?

Hi,

I don't know if this is possible but nasm-rs should evaluate the rust command line options and if -C debuginfo=X is set turn on debug symbols an use -Fdwarf.

After updating to 0.1.8 I'm getting a panic during build:

thread 'main' panicked at 'Invalid version component: ParseIntError { kind: InvalidDigit }', /home/builder/.cargo/registry/src/github.com-1ecc6299db9ec823/nasm-rs-0.1.8/src/lib.rs:325:30

It worked fine with 0.1.7.

On macOS latest Xcode ships something that looks like a 10-year-old fork of nasm, and it's first in $PATH, so it gets used even if a newer (homebrew) nasm is installed, and it doesn't use the same type names as later nasm:

nasm: fatal: unrecognised output format `macho64' - use -hf for a list

$ /Applications/Xcode.app/Contents/Developer/usr/bin/nasm -v
NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Oct 24 2017

$ /Applications/Xcode.app/Contents/Developer/usr/bin/nasm -hf
usage: nasm [-@ response file] [-o outfile] [-f format] [-l listfile]
            [options...] [--] filename
    or nasm -r   for version info (obsolete)
    or nasm -v   for version info (preferred)

    -t          assemble in SciTech TASM compatible mode
    -g          generate debug information in selected format.
    -e          preprocess only (writes output to stdout by default)
    -a          don't preprocess (assemble only)
    -M          generate Makefile dependencies on stdout

    -E<file>    redirect error messages to file
    -s          redirect error messages to stdout

    -F format   select a debugging format

    -I<path>    adds a pathname to the include file path
    -O<digit>   optimize branch offsets (-O0 disables, default)
    -P<file>    pre-includes a file
    -D<macro>[=<value>] pre-defines a macro
    -U<macro>   undefines a macro
    -X<format>  specifies error reporting format (gnu or vc)
    -w+foo      enables warnings about foo; -w-foo disables them
where foo can be:
    macro-params            macro calls with wrong no. of params (default off)
    macro-selfref           cyclic macro self-references (default off)
    orphan-labels           labels alone on lines without trailing `:' (default off)
    number-overflow         numeric constants greater than 0xFFFFFFFF (default on)
    gnu-elf-extensions      using 8- or 16-bit relocation in ELF, a GNU extension (default off)

response files should contain command line parameters, one per line.

valid output formats for -f are (`*' denotes default):
  * bin       flat-form binary files (e.g. DOS .COM, .SYS)
    aout      Linux a.out object files
    aoutb     NetBSD/FreeBSD a.out object files
    coff      COFF (i386) object files (e.g. DJGPP for DOS)
    elf       ELF32 (i386) object files (e.g. Linux)
    as86      Linux as86 (bin86 version 0.3) object files
    obj       MS-DOS 16-bit/32-bit OMF object files
    win32     Microsoft Win32 (i386) object files
    rdf       Relocatable Dynamic Object File Format v2.0
    ieee      IEEE-695 (LADsoft variant) object file format
    macho     NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X object files

I think it'd be best to work around it. Xcode's nasm is so bad, that it's not salvageable.

Hi there, my OS is Windows 10, I've installed nasm from there.

But when I try to compile I get --- stdout cargo:rustc-cfg=nasm_x86_64 --- stderr thread 'main' panicked at 'This version of NASM is too old: No such file or directory (os error 2)', C:\Users\DuckerMan\.cargo\registry\src\github.com-1ecc6299db9ec823\nasm-rs-0.1.7\src\lib.rs:301:25 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

When compiling with cargo, a jobserver is created (through the jobserver crate). The amount of jobs can be set with the option -j and defaults to the amount of CPUs available on the system.

cc-rs implements a client-side to this jobserver to honor the -j option, and I think it could make sense to support this in nasm-rs too (the jobserver crate can be used for this). Rayon does not offer this option AFAIK. It can be configured, but won't coordinate itself with other processes at all.

I understand that this is probably not a high-priority item, but I'd be interested in implementing this myself if you're open to the idea.