| Summary: | avidemux 2.0.40 compile hardened pic gcc O3 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | doejoe |
| Component: | New packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | as.gentoo, hardened, media-video |
| Priority: | High | Keywords: | PMASKED |
| Version: | 2005.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 158340 | ||
| Attachments: | avidemux-2.0.40-pic.patch | ||
|
Description
doejoe
2005-06-17 10:31:15 UTC
Created attachment 63309 [details, diff]
avidemux-2.0.40-pic.patch
This patch *could* fix this, as it uses __PIC__ instead of PIC (similar
problems are in ffmpeg code iirc).
Please test this as I'm not sure if it's the case to apply that if it doesn't
change anything :)
I am sorry but I got the same error. /ADM_filter/libADM_filter.a ./ADM_video/libADM_video.a ./ADM_encoder/libADM_encoder.a ./MPlayer_pp/libMPlayer_pp.a ./ADM_codecs/libADM_codecs.a ./ADM_vp32/libADM_vp32.a ./ADM_audiofilter/libADM_audiofilter.a ./libtoolame/liblibtoolame.a ./ADM_gui2/libADM_gui2.a ./mpeg2enc/libmpeg2enc.a ./ADM_gui/libADM_gui.a ./ADM_inpics/libADM_inpics.a ./ADM_3gp/libADM_3gp.a ./ADM_h263/libADM_h263.a ./ADM_nuv/libADM_nuv.a ./ADM_ogm/libADM_ogm.a ./ADM_audiodevice/libADM_audiodevice.a ./ADM_mpeg2dec/libADM_mpeg2dec.a ./ADM_xvidratectl/libADM_xvidratectl.a ./ADM_ocr/libADM_ocr.a ./ADM_dialog/libADM_dialog.a ./ADM_mpegindexer/libADM_mpegindexer.a ./ADM_mpeg2dec/libADM_mpeg2dec.a ./libMpeg2Dec/liblibMpeg2Dec.a ./ADM_toolkit/libADM_toolkit.a ./ADM_colorspace/libADM_colorspace.a ../adm_lavcodec/libpostproc/libpostproc.a ./ADM_library/libADM_library.a -lXv -lmp3lame -la52 -lfaac -lfaad -lasound -lm -ldl -lpthread -lm -ldl -lpthread -lm -ldl -lpthread -lxvidcore -lxvidcore /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: ../adm_lavcodec/libavcodec.a(dsputil_mmx.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../adm_lavcodec/libavcodec.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [avidemux2] Error 1 make[3]: Leaving directory `/var/tmp/portage/avidemux-2.0.40-r1/work/avidemux-2.0.40/avidemux' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/avidemux-2.0.40-r1/work/avidemux-2.0.40/avidemux' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/avidemux-2.0.40-r1/work/avidemux-2.0.40' make: *** [all] Error 2 That was from the emerge or after applying by hand the patch over the semi-compiled sources in /var/tmp/portage ? Please test and see if latest revision works. Removing myself from the CC as I'm on the hardened alias. Tested with CFLAGS="-fomit-frame-pointer" USE="xv xvid -mmx oss" emerge $(basename $(pwd)) fomit-frame-pointer was needed or we errored out even sooner with a GENERAL_REGS error telling us that all registers are in use. The finial fatal classic error fails later on with. msmpeg4.c: In function `msmpeg4_encode_dc': msmpeg4.c:720: error: can't find a register in class `BREG' while reloading `asm' Reopening then... hardened, maybe it's better to just mask avidemux in your profile until a newer fixed version is in portage? As this is x86-specific, CCing x86@g.o per profile package masking should not be abused. The only time it is allowed is when merging a given package will break your system. # 27 Sep 2004; <carpaski@gentoo.org> (gentoo-core mailing list) # Profiles have a package.mask for ARCHITECTURE related masking. There # must be an explicitly defined reason for using this file in any # particular way. It is NOT a general-use file. It is for specific # instances that involve incompatibilities between libs and specific # profiles. With that said this package problems can be worked around by passing -nopie
durring the compile to C{XX,}FLAGS -fomit-frame-pointer (disable ssp if needed).
However that does not work as this package does not use CXX flags
properly for all source code.
flameeyes, dont abuse.. this is hardened.. not x86.. (it can also be considered x86... there was similar problems before.. oh well) I've added a patch to respect CXXFLAGS as configure.in.in was a bit broken, now should be better. News? Reopen if it's still an issue, close if it's fixed. *** Bug 117249 has been marked as a duplicate of this bug. *** Still broken... removed from tree, file a new bug if an issue with 2.3.0 |
