Erro durante a construção estática de libvorbis e libmp3lame

1

Estou tendo problemas ao tentar construir um binário estático do ffmpeg - Eu tenho quase toda a construção funcionando, com a exceção de duas libs - libvorbis e libmp3lame.

Estas duas bibliotecas estão falhando durante ./configure, especificamente em funções indefinidas do math.h / libm :

libvorbis:

gcc -L/vol/build/lib -static -static-libstdc++ -static-libgcc -Wl,--as-needed -Wl,-z,noexecstack -I/vol/build/include -L/vol/build/lib -o /tmp/ffconf.UKKLGhCv/test /tmp/ffconf.UKKLGhCv/test.o -lvorbis -lm -logg -lstdc++ -lpthread -lexpat -ldl -lm --enable-libopencore-amrnb
/vol/build/lib/libvorbis.a(envelope.o): In function '_ve_envelope_init':
envelope.c:(.text+0x983): undefined reference to '_ZGVbN2v_sin'
envelope.c:(.text+0x9a9): undefined reference to '_ZGVbN2v_sin'
/vol/build/lib/libvorbis.a(lsp.o): In function 'vorbis_lsp_to_curve':
lsp.c:(.text+0x650): undefined reference to '_ZGVbN2v_cos'
lsp.c:(.text+0x669): undefined reference to '_ZGVbN2v_cos'


libmp3lame:

gcc -L/vol/build/lib -static -static-libstdc++ -static-libgcc -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.dC4w1f5B/test /tmp/ffconf.dC4w1f5B/test.o -lmp3lame -lm -lstdc++ -lpthread -lexpat -ldl -lm --enable-libopencore-amrnb
/vol/build/lib/libmp3lame.a(psymodel.o): In function 'init_s3_values':
psymodel.c:(.text+0x14d3): undefined reference to '_ZGVbN2v___exp_finite'
psymodel.c:(.text+0x14fa): undefined reference to '_ZGVbN2v___exp_finite'
/vol/build/lib/libmp3lame.a(psymodel.o): In function 'psymodel_init':
psymodel.c:(.text+0xb62d): undefined reference to '_ZGVbN4vv___powf_finite'
psymodel.c:(.text+0xb677): undefined reference to '_ZGVbN4vv___powf_finite'
psymodel.c:(.text+0xb6c4): undefined reference to '_ZGVbN4vv___powf_finite'
psymodel.c:(.text+0xb711): undefined reference to '_ZGVbN4vv___powf_finite'
psymodel.c:(.text+0xb75b): undefined reference to '_ZGVbN4vv___powf_finite'
/vol/build/lib/libmp3lame.a(psymodel.o):psymodel.c:(.text+0xb7a2): more undefined references to '_ZGVbN4vv___powf_finite' follow
/vol/build/lib/libmp3lame.a(util.o): In function 'fill_buffer':
util.c:(.text+0x28a6): undefined reference to '_ZGVbN2v_cos'
util.c:(.text+0x28cc): undefined reference to '_ZGVbN2v_cos'
util.c:(.text+0x28fb): undefined reference to '_ZGVbN2v_cos'
util.c:(.text+0x2921): undefined reference to '_ZGVbN2v_cos'
util.c:(.text+0x29cc): undefined reference to '_ZGVbN2v_sin'
util.c:(.text+0x29e8): undefined reference to '_ZGVbN2v_sin'

Não consigo descobrir como obtê-los com sucesso. Pelo que entendi, passando a opção -lm deve ser suficiente, mas aparentemente não é. Eu verifiquei a presença de libm.a , que está localizado em /usr/lib/x86_64-linux-gnu/libm.a , eu também tentei passar este diretório no -L flags, mas nenhuma diferença. As libs constroem bem ao remover o -static flag, mas o binário resultante é (duh) ligado ao libm.so.

Apenas no caso, essas são as sinalizações que estou usando para criar as duas bibliotecas:

libvorbis:
./configure --prefix=${CMAKE_BINARY_DIR} --disable-shared --disable-oggtest

libmp3lame:
./configure --prefix=${CMAKE_BINARY_DIR} --disable-shared

Eu apreciaria quaisquer dicas sobre como corrigir ou depurar isso ainda mais.

Edit: depois de brincar um pouco mais, parece que o libm está sendo vinculado - quando eu removo o -lm flag, estou obtendo uma tonelada de referências mais indefinidas - sin , cos , __pow_finite , etc. Quando eu o coloco de volta, a maioria deles desaparece e apenas os símbolos mutilados, como _ZGVbN4vv___powf_finite e _ZGVbN2v_cos , permanecem.

    
por kralewitz 27.05.2018 / 21:34

1 resposta

1

Bem, eu consegui resolvê-lo - pesquisar os símbolos mutilados como _ZGVbN2v_cos me levou a esse patch mencionando matemática vetorial e, em combinação com a saída de ldd durante a vinculação dinâmica mencionando libmvec , percebi que Eu poderia ter que vincular isso também.

Para o libmp3lame, ele deve ser ligado antes do libm:

gcc -L/vol/build/lib -static -o /tmp/ffconf.dC4w1f5B/test /tmp/ffconf.dC4w1f5B/test.o -lmp3lame -lmvec -lm

Para libvorbis, a ordem de -lm e -lmvec não importa, ele constrói de qualquer forma.

    
por 28.05.2018 / 09:09