Bug#501002: marked as done (ffmpeg: ffserver won't start, giving "undefined symbol: ffm_read_write_index")

[Reinhard Tartler]

Fabian Greffrath <greffrath at leat.rub.de> writes:

> Reinhard Tartler schrieb:
>> The ffserver binary itself is build without altivec, however libavcodec
>> and libavformat are compiled in both modes. The ffserver binary itself
>> doesn't really benefit from altivec anyways (other the libavcodec
>> binary...)
>
> But then I don't understand why it misses symbols in the accelerated
> library when it is built against the unaccelerated one.

Have a look in ffm.c, line 713:

#ifdef CONFIG_FFSERVER
offset_t ffm_read_write_index(int fd)
{
    uint8_t buf[8];

    lseek(fd, 8, SEEK_SET);
    read(fd, buf, 8);
    return AV_RB64(buf);
}

void ffm_write_write_index(int fd, offset_t pos)
{
    uint8_t buf[8];
    int i;

    for(i=0;i<8;i++)
        buf[i] = (pos >> (56 - i * 8)) & 0xff;
    lseek(fd, 8, SEEK_SET);
    write(fd, buf, 8);
}

void ffm_set_write_index(AVFormatContext *s, offset_t pos, offset_t file_size)
{
    FFMContext *ffm = s->priv_data;
    ffm->write_index = pos;
    ffm->file_size = file_size;
}
#endif // CONFIG_FFSERVER



> Will other applications possibly behave similar (which would be a
> catastrophe for our current packaging)?

If other applications would use the ifdef'ed symbols, yes. They would
have been fixed by the last upload as well.

The problem here is that I didn't check hard enough that the 2 flavors
of the shared libraries are actually compatible. I do hope that I didn't
make any further mistakes.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4