Проблема с x86_64-w64-mingw32: ld используется не тот, что надо, и ругается

надо чтобы кросс-binutils, внезапно, были в PATH, и не более

x86_64-w64-mingw32-ld и прочее

не похоже: он целенаправленно использует /usr/x86_64-pc-linux-gnu/bin/ld, т.е. в каких-то переменных окружения это прописано, но не ясно в каких, ибо компилятор он юзает правильный, x86_64-w64-mingw32-gcc. Кстати, через libtool...

Похожена ошибку в make.conf. Как build.log и config.log выглядит?

У меня с дефолтным embedded profile собирается (нужно только bzero на memset поменять).

ARCH=amd64 x86_64-w64-mingw32-emerge -1 media-libs/libsdl

У меня с embedded не собирался вообще mingw. В инструкции написано:

As of spring 2016, the default embedded profile that /usr/i686-w64-mingw32/etc/portage/profile/make.profile points to actually excludes all three of the above variables from being set in make.conf. In order to rectify this, at this point in time the easiest way is to use the prefix/windows/winnt profile

Я его подменил.

make.conf таков:

CHOST=x86_64-w64-mingw32
CBUILD=x86_64-pc-linux-gnu
ARCH=amd64

HOSTCC=x86_64-pc-linux-gnu

ROOT=/usr/${CHOST}/

ACCEPT_KEYWORDS="amd64 ~amd64"

USE="${ARCH} -pam"

CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/

ELIBC="mingw"

PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"

Но, например, опции CBUILD и HOSTCC я менял, а он их вообще не использует

Upd: поставил embedded — опять же ругается на ld...

build.log: https://pastebin.com/uDz9dSZV

checking for x86_64-w64-mingw32-g++... no

Это плохо. media-libs/audiofile на c++ написан. cross-x86_64-w64-mingw32/gcc с USE=cxx собран?

действительно, без cxx... Сейчас пересоберу, отпишусь о результатах

нужно только bzero на memset поменять

Добавил как https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b9209b71f8b151cf6dfdd20...

Спасибо, пересборка помогла! Пришлось помучиться с заменой bzero на memset, но я кое-как справился...

Кстати, чтобы два раза не вставать (как говорится): как использовать эти мудрёные /etc/portage/patches? Действовал по https://wiki.gentoo.org/wiki//etc/portage/patches. Не понял, надо ли в ebuild для audiofile добавлять eapply_user, но на всякий пожарный добавил:

src_prepare() {
    default
    eapply_user
    eautoreconf
}

Сгенерировал новый digest, emerge запускается, но, похоже, положенный куда надо патч не применяет...

Положил я его в /usr/portage/patches/media-libs/audiofile-0.3.6-r3/memset.patch, выглядит так:

--- audiofile-0.3.6/libaudiofile/CAF.cpp        2013-03-06 09:30:03.000000000 +0400
+++ /tmp/CAF.cpp        2017-06-08 23:48:34.134396320 +0300
@@ -706,3 +706,3 @@ void CAFFile::initALACCompressionParams(
        m_codecData = new Buffer(codecDataSize);
-       bzero(m_codecData->data(), m_codecData->size());
+       memset(m_codecData->data(), 0, m_codecData->size());

Тест из https://wiki.gentoo.org/wiki/Mingw у меня не собрался (пишет кучу «undefined reference»), поскольку, видимо, не динамическая библиотека SDL получилась, а статическая. Решение (подсмотрено здесь):

x86_64-w64-mingw32-gcc -o test.exe test.c `/usr/x86_64-w64-mingw32/usr/bin/sdl-config --libs` -lwinmm -lgdi32 -ldxguid

Примеры test.c и hello.c собираются, но только под рутом, и wine с ними ничего не выводит...

Похоже, тут я просто невнимательно мануал читал... надо было патч класть в /usr/x86_64-w64-mingw32/etc/portage/patches...

Проще намейкинсталлить, на самом деле. Там собирать то нечего - gmp, mpfr, mpc, cloog-ppl, binutils, mingw-runtime, gcc

У меня при сборке libsdl говорит, что динамическая сборка libsdl не происходит из-за отсутствия dxguid.dll (или .lib) (из cross-x86_64-w64-mingw32/mingw64-runtime):

*** Warning: linker path does not have real file for library -ldxguid.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdxguid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/x86_64-w64-mingw32/lib/libdxguid.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Не знаю можно ли cross-x86_64-w64-mingw32/mingw64-runtime собирать .lib заглушки или предполагается подсовывать .dll с целевой системы.