Christian Marillat maril...@free.fr added the comment:
Bug closed.
--
status: open - closed
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1182
Diego Biurrun di...@biurrun.de added the comment:
Mark bug as fixed.
--
substatus: - fixed
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1182
Christian Marillat maril...@free.fr added the comment:
Sorry for the delay.
I did a svn build today with --enable-hardcoded-tables without problem.
Thanks for your work.
Christian
Christian
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Thu, Dec 03, 2009 at 03:35:15PM +, Christian Marillat wrote:
Christian Marillat maril...@free.fr added the comment:
Sorry for the delay.
I did a svn build today with --enable-hardcoded-tables without problem.
It is
Diego Biurrun di...@biurrun.de added the comment:
On Thu, Dec 03, 2009 at 03:35:15PM +, Christian Marillat wrote:
Sorry for the delay.
I did a svn build today with --enable-hardcoded-tables without problem.
If the problem is fixed, please close the issue.
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Tue, Oct 13, 2009 at 10:32:48AM +, Reimar Döffinger wrote:
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Sun, Oct 04, 2009 at 11:03:30AM +, Christian Marillat wrote:
Christian Marillat
Christian Marillat maril...@free.fr added the comment:
Where are these patches ?
Otherwise the ffmpeg build fine with --enable-small
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1182
Mans Rullgard m...@mansr.com added the comment:
Reimar Döffinger iss...@roundup.ffmpeg.org writes:
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Tue, Oct 13, 2009 at 11:29:24AM +, Reimar Döffinger wrote:
and configuring with --enable-small --enable-hardcoded-tables
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Duplicate of issue 711.
Which one should be closed?
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1182
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Thu, Oct 01, 2009 at 12:05:38AM +, varenet wrote:
varenet t-b...@parisc-linux.org added the comment:
re readelf: here it is:
$ readelf -S libavcodec/libavcodec.so
There are 42 section headers, starting at offset
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Sun, Oct 04, 2009 at 07:32:08AM +, Reimar Döffinger wrote:
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Thu, Oct 01, 2009 at 12:05:38AM +, varenet wrote:
varenet t-b...@parisc-linux.org added
Christian Marillat maril...@free.fr added the comment:
Still the same.
With -ffunction-sections -fdata-sections
libavcodec/mpeg12enc.o: In function `ff_mpeg1_encode_init':
/tmp/buildd/ffmpeg-dmo-0.5+svn20091001/libavcodec/mpeg12enc.c:802: relocation
truncated to fit: GPREL22 against
Christian Marillat maril...@free.fr added the comment:
I did a gcc bug report :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1182
Christian Marillat maril...@free.fr added the comment:
Aded myself to nosy
--
nosy: +marillat
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1182
Mans Rullgard m...@mansr.com added the comment:
varenet t-b...@parisc-linux.org added the comment:
$ readelf -S libavcodec/libavcodec.so
There are 42 section headers, starting at offset 0x1805d38:
Section Headers:
[Nr] Name Type Address Offset
varenet t-b...@parisc-linux.org added the comment:
I'm experiencing the same problem. Here's a summary of the issue:
- The issue arises only when building with --enable-shared.
- The issue apparently consists in a relocation overflow (I'm suspecting very
large tables are being allocated on the
Diego Biurrun di...@biurrun.de added the comment:
On Wed, Sep 30, 2009 at 08:25:33PM +, varenet wrote:
PS: I can provide remote access to an ia64 box if that can help.
Maybe you would be interested in hosting a FATE box for IA64?
Diego
Reimar Döffinger b...@reimardoeffinger.de added the comment:
On Wed, Sep 30, 2009 at 08:25:33PM +, varenet wrote:
- The issue apparently consists in a relocation overflow (I'm suspecting very
large tables are being allocated on the stack), with the following type of
compiler output during
Mans Rullgard m...@mansr.com added the comment:
varenet t-b...@parisc-linux.org added the comment:
I'm experiencing the same problem. Here's a summary of the issue:
- The issue arises only when building with --enable-shared.
- The issue apparently consists in a relocation overflow (I'm
varenet t-b...@parisc-linux.org added the comment:
re FATE: care to elaborate? I'm not familiar with this particular klingon.
re readelf: here it is:
$ readelf -S libavcodec/libavcodec.so
There are 42 section headers, starting at offset 0x1805d38:
Section Headers:
[Nr] Name
Diego Biurrun di...@biurrun.de added the comment:
On Thu, Oct 01, 2009 at 12:05:38AM +, varenet wrote:
varenet t-b...@parisc-linux.org added the comment:
re FATE: care to elaborate? I'm not familiar with this particular klingon.
http://fate.multimedia.cx/
PS: can someone educate me
varenet t-b...@parisc-linux.org added the comment:
FATE looks like something I could indeed host. I need to checkout its
requirements storage/cpu/network-wise, but it should be feasible. I have parisc
and ia64 machines available.
--
nosy: +varenet
22 matches
Mail list logo
