libiconv is already defined per-platform.  The actual libiconv library
won't be built on platforms like Linux where it doesn't need to be, so
there's no need to maintain a separate platform list here.

Required to build for FreeBSD.

Commit moved to staging branch from PR #212669 (commit 8d2255d).

Maintenance release

Changes: https://github.com/Libvisual/libvisual/blob/libvisual-0.4.1/libvisual/NEWS#L6

lsof: 4.96.5 -> 4.98.0

dejagnu: fix target passing for 'runtest' wrapper

For Linux and Darwin, it uses $(CC), but for BSD it hardcodes ld for
some reason.

A ton of cleanup and refactoring went into this. Too much to list.

Co-authored-by: Anderson Torres <[email protected]>
Co-authored-by: Martin Weinelt <[email protected]>

Our regular ffmpeg should have everything enabled Jami needs, if not that's a
bug we should fix in our ffmpeg rather than in jami

Fixes #211297

Fixes #189180

Upstream issue: xiph/opusfile#36

ffmpeg: merge with ffmpeg-full

A few potentially disruptive changes:

- binutils does not embed ${binutils-unwrapped}/lib as a default library
  search path anymore. This will cause link failures for -lbfd -lopcodes
  users that did not declare their dependency on those libraries. They
  will need to add `libbfd` and `libopcodes` attributes to build inputs.

- `libbfd` and `libopcodes` attributes now just reference
  `binutils-unwrapped.{dev,lib}` pair of attributes without patching
  `binutils` build system.

We don't patch build system anymore and use multiple outputs out of
existing `binutils` build. That makes the result more maintainable: no
need to handle ever growing list of dependencied of `libbfd`. This time
new addition was `libsframe`.

To accomodate `out` / `lib` output split I had to remove `lib` -> `bin`
backreference by removing legacy lookup path for plugins.

I also did not enable `zstd` just yet as `nixpkgs` version of `zstd`
package pulls in `cmake` into bootstrap sequence.

Changes: https://lists.gnu.org/archive/html/info-gnu/2023-01/msg00003.html

opusfile: apply patch for CVE-2022-47021

with GCC 12

Co-authored-by: Weijia Wang <[email protected]>

…#215989)

Without the change `pkgsMusl.pkgsStatic.buildPackages.binutils.bintools`
build fails as:

    $ ln: failed to create symbolic link './include': File exists

This happens because both host and target are `x86_64-unknown-linux-musl`.
But `hostPlatform` differs from `targetPlatform` by `isStatic` value.

By `./configure`'s standard it's not yet a cross-compilation. The change
tries to move things around only when tuples change.

Our openjdk derivations fail to build with `-march=opteron` (via
either `NIX_CFLAGS_COMPILE` or `hostPlatform.gcc.arch`).  This was
fixed upstream in gcc12 but not carried back to gcc11:

  https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d243f4009d8071b734df16cd70f4c5d09a373769

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910

Since gcc11 is still nixpkgs' primary compiler, this PR cherry-picks
the fix out of gcc12.

Unfortunately since `-march=` can be added after the `gcc11`
derivation is built we can't apply this patch conditionally (which
we don't usually do anyways).

...into staging-next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910