On 11.05.2016, at 17:00, Bruce Dawson
wrote:
> Microsoft is aware of the issue and is working on it. They might fix it.
> They might not, however, because regressions in non-standard behavior are
> not as serious. We will see.
>
> I'm committing a Chromium specific workaround because that allow
Microsoft is aware of the issue and is working on it. They might fix it.
They might not, however, because regressions in non-standard behavior are
not as serious. We will see.
I'm committing a Chromium specific workaround because that allows us to
test Microsoft's new optimizer - I want to be able
On Wed, May 11, 2016 at 4:19 PM, Bruce Dawson
wrote:
> The error is:
>
> wavdec.obj : error LNK2001: unresolved external symbol _ff_w64_guid_data
>
> This happens because the compiler does not recognize early enough
> that _ff_w64_guid_data is never actually needed, so it creates a reference
>
The error is:
wavdec.obj : error LNK2001: unresolved external symbol _ff_w64_guid_data
This happens because the compiler does not recognize early enough
that _ff_w64_guid_data is never actually needed, so it creates a reference
to it.
I am adding a temporary fix to Chromium's ffmpeg repo so
On Tue, May 10, 2016 at 01:22:53PM -0400, Bruce Dawson wrote:
> BTW, the reason I suggested the CONFIG_W64_DEMUXER patch that started this
> email thread is because the pre-release version of VS 2015 Update 3 can't
> handle that code as-is. Microsoft might change their compiler before the
> officia
BTW, the reason I suggested the CONFIG_W64_DEMUXER patch that started this
email thread is because the pre-release version of VS 2015 Update 3 can't
handle that code as-is. Microsoft might change their compiler before the
officially release of Update 3, but currently ffmpeg (in Chromium at least)
d
On 26 April 2016 at 01:49, Carl Eugen Hoyos wrote:
> Matt Oliver gmail.com> writes:
>
> > Even so icl does also suffer from issues when using lto
> > with optimised builds aswell so its not just limited to
> > debug builds.
>
> Can you confirm that this is Windows-only, ie that lto
> works fine
On 4/25/2016 4:49 PM, Carl Eugen Hoyos wrote:
> Can you confirm that this is Windows-only, ie that lto
> works fine on Linux with the Intel compiler?
> (It did work fine when I last tested.)
FWIW, I've had issues with LTO on Linux, with clang and gold, due to (lack of)
DCE.
- Derek
Matt Oliver gmail.com> writes:
> Even so icl does also suffer from issues when using lto
> with optimised builds aswell so its not just limited to
> debug builds.
Can you confirm that this is Windows-only, ie that lto
works fine on Linux with the Intel compiler?
(It did work fine when I last
On 25 April 2016 at 20:42, Michael Niedermayer
wrote:
> On Mon, Apr 25, 2016 at 06:17:22PM +1000, Matt Oliver wrote:
> > On 23 April 2016 at 23:46, wm4 wrote:
> >
> > > On Sat, 23 Apr 2016 14:52:12 +0200
> > > Reimar Döffinger wrote:
> > >
> > > > On 23.04.2016, at 13:21, wm4 wrote:
> > > >
>
On Mon, Apr 25, 2016 at 1:09 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Apr 25, 2016 at 1:17 AM, Matt Oliver wrote:
>
>> Obviously changing things would require a consensus from all the devs.
>> Personally I would like to see the DCE stuff removed as currently as stated
>> debug or lto builds
Hi,
On Mon, Apr 25, 2016 at 1:17 AM, Matt Oliver wrote:
> Obviously changing things would require a consensus from all the devs.
> Personally I would like to see the DCE stuff removed as currently as stated
> debug or lto builds will fail with msvc and these are both options that are
> support b
On Mon, Apr 25, 2016 at 06:17:22PM +1000, Matt Oliver wrote:
> On 23 April 2016 at 23:46, wm4 wrote:
>
> > On Sat, 23 Apr 2016 14:52:12 +0200
> > Reimar Döffinger wrote:
> >
> > > On 23.04.2016, at 13:21, wm4 wrote:
> > >
> > > > On Sat, 23 Apr 2016 01:16:31 +0200
> > > > Hendrik Leppkes wrote
On 23 April 2016 at 23:46, wm4 wrote:
> On Sat, 23 Apr 2016 14:52:12 +0200
> Reimar Döffinger wrote:
>
> > On 23.04.2016, at 13:21, wm4 wrote:
> >
> > > On Sat, 23 Apr 2016 01:16:31 +0200
> > > Hendrik Leppkes wrote:
> > >
> > >> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> > >> wrote:
> >
On Sat, 23 Apr 2016 14:52:12 +0200
Reimar Döffinger wrote:
> On 23.04.2016, at 13:21, wm4 wrote:
>
> > On Sat, 23 Apr 2016 01:16:31 +0200
> > Hendrik Leppkes wrote:
> >
> >> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> >> wrote:
> >>> I've noticed that when CONFIG_W64_DEMUXER is defin
On 23.04.2016, at 13:21, wm4 wrote:
> On Sat, 23 Apr 2016 01:16:31 +0200
> Hendrik Leppkes wrote:
>
>> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
>> wrote:
>>> I've noticed that when CONFIG_W64_DEMUXER is defined to zero that ffmpeg
>>> compiles in a reference to ff_w64_guid_data but doesn'
On Sat, Apr 23, 2016 at 1:21 PM, wm4 wrote:
> On Sat, 23 Apr 2016 01:16:31 +0200
> Hendrik Leppkes wrote:
>
>> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
>> wrote:
>> > I've noticed that when CONFIG_W64_DEMUXER is defined to zero that ffmpeg
>> > compiles in a reference to ff_w64_guid_data bu
On Sat, 23 Apr 2016 01:16:31 +0200
Hendrik Leppkes wrote:
> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> wrote:
> > I've noticed that when CONFIG_W64_DEMUXER is defined to zero that ffmpeg
> > compiles in a reference to ff_w64_guid_data but doesn't not link w64.o
> > (which defines that symbo
On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
wrote:
> I've noticed that when CONFIG_W64_DEMUXER is defined to zero that ffmpeg
> compiles in a reference to ff_w64_guid_data but doesn't not link w64.o
> (which defines that symbol).
>
> This normally works because most optimizers discard the refere
I've noticed that when CONFIG_W64_DEMUXER is defined to zero that ffmpeg
compiles in a reference to ff_w64_guid_data but doesn't not link w64.o
(which defines that symbol).
This normally works because most optimizers discard the reference
to ff_w64_guid_data early enough to not cause a linker fail
20 matches
Mail list logo
