Здесь есть несколько решений;и, вероятно, тот, который уклонился от меня.
Самый простой и быстрый способ - добавить --disable-dependency-tracking к вашему запуску ./configure.
Это скажет негенерировать зависимости вообще.Фаза зависимости - это то, что вас убивает, потому что параметры -M используются во время генерации кода;что нельзя сделать, если нацелено несколько архитектур.
Так что это нормально, если вы делаете чистую сборку на чужом пакете;или вы не против делать «чистку» перед каждой сборкой.Если вы взламываете исходный код, особенно заголовочные файлы, это не очень хорошо, так как make, вероятно, не будет знать, что пересобирать, и у вас останутся устаревшие двоичные файлы.
Лучше, но большеопасно делать что-то вроде:
CC=clang CXX=clang++ ./configure
Это заставит компилятор звенеть вместо gcc.У вас есть лязг, если у вас есть недавний Xcode.Configure поймет, что clang отвечает требованиям компиляции, но также решит, что это небезопасно для генерации автозависимостей.Вместо того, чтобы отключить автозависимость gen, он выполнит генерацию в два прохода в старом стиле.
Одно предостережение: это может или не может работать, как я описал, в зависимости от того, как вы устанавливаете свои флаги архитектуры.Если у вас есть флаги, которые вы хотите передать всем вызовам компилятора (то есть: -I для путей включения), вы должны установить CPPFLAGS.Для генерации кода установите CFLAGS и CXXFLAGS для C и C ++ (и я полагаю, COBJFLAGS для ObjC).Обычно вы добавляете $ CPPFLAGS к ним.Обычно я запускаю сценарий оболочки что-то вроде:
#!/bin/bash
export CC=clang
export CXX=clang
export CPPFLAGS="-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -fvisibility=hidden"
export CFLAGS="-arch i386 -arch x86_64 -O3 -fomit-frame-pointer -momit-leaf-frame-pointer -ffast-math $CPPFLAGS"
export CXXFLAGS=$CFLAGS
./configure
Возможно, вам не нужны эти точные флаги, но это должно дать вам представление.
lipo,Вы были на этом пути, это звучит как.Я нашел лучший способ заключается в следующем:
а.Создайте каталоги верхнего уровня, такие как .X86_64 и .i386.Обратите внимание '.'спереди.Если вы нацеливаете сборку на каталоги с исходными текстами, обычно нужно начинать с точки, чтобы потом не испортить 'make clean'.
b.Запустите ./configure с чем-то вроде: --prefix = `pwd` / .i386` и, тем не менее, вы установите архитектуру (в данном случае i386).
c.Сделайте make, и make install, и при условии, что все прошло хорошо make clean и убедитесь, что материал все еще в .i386 Повторите для каждой архитектуры.make clean в конце каждого этапа очень важен, так как перенастройка может изменить то, что очищается, и вы действительно хотите убедиться, что вы не загрязняете архитектуру старыми файлами архитектуры.
d.Предполагая, что у вас есть все ваши сборки, как вы хотите, я обычно делаю сценарий оболочки, который выглядит и чувствует что-то вроде этого, чтобы запускаться в конце, что подстерегает вас.
# move the working builds for posterity and debugging
mv .i386 ./Build/i386
mv .x86_64 ./Build/x86_64
for path in ./Build/i386/lib/*
do
file=${path##*/}
# only convert 'real' files
if [ -f "$file" -a ! -L "$file" ]; then
partner="./Build/x86_64/Lib/$file"
if [ -f $partner -a ! -L $partner ]; then
target="./Build/Lib/$file"
lipo -create "$file" "$partner" -output "$target" || { echo "Lipo failed to get phat"; exit 5; }
echo Universal Binary Created: $target
else
echo Skipping: $file, no valid architecture pairing at: $partner
fi
else
# this is a pretty common case, openssl creates symlinks
# echo Skipping: $file, NOT a regular file
true
fi
done
Что я НЕ понял, так это магия, которая позволила бы мне использовать gcc и старый школьный двухпроходный депе.Честно говоря, меня все меньше и меньше волнует каждый день, так как я все больше и больше впечатляюсь clang / llvm.