Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-29 Thread Stefan Dirsch
On Tue, Jan 28, 2020 at 11:45:39AM -0800, Dylan Baker wrote:
> Quoting Ian Romanick (2020-01-21 09:50:47)
> > On 1/20/20 6:41 AM, Stefan Dirsch wrote:
> > > Hi
> > > 
> > > Starting from the upcoming GCC release 10, the default of -fcommon option 
> > > will
> > > change to -fno-common. Due to this we're going to see a lot of build 
> > > failures
> > 
> > It seems like many of the places where this would occur in Mesa are
> > likely to be fine... but it would be easy enough to fix by sprinkling
> > 'extern' around (if my understanding of the GCC docs is correct).  It
> > also seems unlikely that GCC will be able to apply any hypothetical
> > optimizations to the uses in Mesa.  I think most places where a global
> > is intended to be isolated, we already decorate it with static.
> > 
> > See also
> > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fcommon
> > 
> > We definitely should decide which behavior we want, and we should start
> > enforcing it sooner rather than later.
> > 
> > > in Mesa drivers like
> > > 
> > > multiple definition of `syncobj_handle'; 
> > > src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
> > >  (symbol from plugin):(.text+0x0): first defined here
> > > [  213s]
> > > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> > > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol 
> > > from
> > > plugin): in function 
> > > `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> > > 
> > > I'm wondering if there is already anybody working on fixing these issues 
> > > or is
> > > it recommended to workaround it by setting -fcommon manually somehow? How 
> > > can
> > > the latter be done when using meson/ninja as build tool?
> > 
> > I know you can do it with buildtype=plain, but that may be overkill for
> > anything other than testing.
> 
> meson -Dc_args=-fcommon -Dcpp_args=-fcommon 
> 
> will do what you want.

Thanks a lot for the hint!

> I agree that we should probably either add -fcommon or -fno-common to the
> meson/scons/android build files, so that we don't get cases of "but this works
> on my dev machine with $complier!"

I agree on that.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-28 Thread Dylan Baker
Quoting Ian Romanick (2020-01-21 09:50:47)
> On 1/20/20 6:41 AM, Stefan Dirsch wrote:
> > Hi
> > 
> > Starting from the upcoming GCC release 10, the default of -fcommon option 
> > will
> > change to -fno-common. Due to this we're going to see a lot of build 
> > failures
> 
> It seems like many of the places where this would occur in Mesa are
> likely to be fine... but it would be easy enough to fix by sprinkling
> 'extern' around (if my understanding of the GCC docs is correct).  It
> also seems unlikely that GCC will be able to apply any hypothetical
> optimizations to the uses in Mesa.  I think most places where a global
> is intended to be isolated, we already decorate it with static.
> 
> See also
> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fcommon
> 
> We definitely should decide which behavior we want, and we should start
> enforcing it sooner rather than later.
> 
> > in Mesa drivers like
> > 
> > multiple definition of `syncobj_handle'; 
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
> >  (symbol from plugin):(.text+0x0): first defined here
> > [  213s]
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> > plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> > 
> > I'm wondering if there is already anybody working on fixing these issues or 
> > is
> > it recommended to workaround it by setting -fcommon manually somehow? How 
> > can
> > the latter be done when using meson/ninja as build tool?
> 
> I know you can do it with buildtype=plain, but that may be overkill for
> anything other than testing.

meson -Dc_args=-fcommon -Dcpp_args=-fcommon 

will do what you want.

I agree that we should probably either add -fcommon or -fno-common to the
meson/scons/android build files, so that we don't get cases of "but this works
on my dev machine with $complier!"

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-23 Thread Timur Kristóf
I've fixed most of the problems in 2385, but the problem still remains
in omx. Could someone who's familiar with omx please take a look?

Alternatively, maybe we can try adding -fcommon to just omx, until this
issue is resolved.

On Tue, 2020-01-21 at 18:49 +0100, Bas Nieuwenhuizen wrote:
> I think this ended up spawning a bunch of work in
> https://gitlab.freedesktop.org/mesa/mesa/issues/2385
> 
> On Mon, Jan 20, 2020 at 3:41 PM Stefan Dirsch 
> wrote:
> > Hi
> > 
> > Starting from the upcoming GCC release 10, the default of -fcommon
> > option will
> > change to -fno-common. Due to this we're going to see a lot of
> > build failures
> > in Mesa drivers like
> > 
> > multiple definition of `syncobj_handle'; src/amd/vulkan/9198681@@
> > vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o (symbol
> > from plugin):(.text+0x0): first defined here
> > [  213s]
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-
> > linux/bin/ld:
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o
> > (symbol from
> > plugin): in function
> > `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> > 
> > I'm wondering if there is already anybody working on fixing these
> > issues or is
> > it recommended to workaround it by setting -fcommon manually
> > somehow? How can
> > the latter be done when using meson/ninja as build tool?
> > 
> > Thanks,
> > Stefan
> > 
> > Public Key available
> > --
> > Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
> > Tel: 0911-740 53 0Maxfeldstraße 5
> > FAX: 0911-740 53 479  D-90409 Nürnberg
> > http://www.suse.deGermany
> > 
> > (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-22 Thread Stefan Dirsch
On Tue, Jan 21, 2020 at 06:49:59PM +0100, Bas Nieuwenhuizen wrote:
> I think this ended up spawning a bunch of work in
> https://gitlab.freedesktop.org/mesa/mesa/issues/2385

Thanks a lot! These patches (already in master) fixed my build issues with
"-fno-common" compiler flag. :-)

Stefan

> On Mon, Jan 20, 2020 at 3:41 PM Stefan Dirsch  wrote:
> >
> > Hi
> >
> > Starting from the upcoming GCC release 10, the default of -fcommon option 
> > will
> > change to -fno-common. Due to this we're going to see a lot of build 
> > failures
> > in Mesa drivers like
> >
> > multiple definition of `syncobj_handle'; 
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
> >  (symbol from plugin):(.text+0x0): first defined here
> > [  213s]
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> > plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> >
> > I'm wondering if there is already anybody working on fixing these issues or 
> > is
> > it recommended to workaround it by setting -fcommon manually somehow? How 
> > can
> > the latter be done when using meson/ninja as build tool?

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-21 Thread Ian Romanick
On 1/20/20 6:41 AM, Stefan Dirsch wrote:
> Hi
> 
> Starting from the upcoming GCC release 10, the default of -fcommon option will
> change to -fno-common. Due to this we're going to see a lot of build failures

It seems like many of the places where this would occur in Mesa are
likely to be fine... but it would be easy enough to fix by sprinkling
'extern' around (if my understanding of the GCC docs is correct).  It
also seems unlikely that GCC will be able to apply any hypothetical
optimizations to the uses in Mesa.  I think most places where a global
is intended to be isolated, we already decorate it with static.

See also
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fcommon

We definitely should decide which behavior we want, and we should start
enforcing it sooner rather than later.

> in Mesa drivers like
> 
> multiple definition of `syncobj_handle'; 
> src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
>  (symbol from plugin):(.text+0x0): first defined here
> [  213s]
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> 
> I'm wondering if there is already anybody working on fixing these issues or is
> it recommended to workaround it by setting -fcommon manually somehow? How can
> the latter be done when using meson/ninja as build tool?

I know you can do it with buildtype=plain, but that may be overkill for
anything other than testing.

> Thanks,
> Stefan
> 
> Public Key available
> --
> Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
> Tel: 0911-740 53 0Maxfeldstraße 5
> FAX: 0911-740 53 479  D-90409 Nürnberg
> http://www.suse.deGermany 
> 
> (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-21 Thread Bas Nieuwenhuizen
I think this ended up spawning a bunch of work in
https://gitlab.freedesktop.org/mesa/mesa/issues/2385

On Mon, Jan 20, 2020 at 3:41 PM Stefan Dirsch  wrote:
>
> Hi
>
> Starting from the upcoming GCC release 10, the default of -fcommon option will
> change to -fno-common. Due to this we're going to see a lot of build failures
> in Mesa drivers like
>
> multiple definition of `syncobj_handle'; 
> src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
>  (symbol from plugin):(.text+0x0): first defined here
> [  213s]
> /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
>
> I'm wondering if there is already anybody working on fixing these issues or is
> it recommended to workaround it by setting -fcommon manually somehow? How can
> the latter be done when using meson/ninja as build tool?
>
> Thanks,
> Stefan
>
> Public Key available
> --
> Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
> Tel: 0911-740 53 0Maxfeldstraße 5
> FAX: 0911-740 53 479  D-90409 Nürnberg
> http://www.suse.deGermany
> 
> (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

2020-01-20 Thread Stefan Dirsch
Hi

Starting from the upcoming GCC release 10, the default of -fcommon option will
change to -fno-common. Due to this we're going to see a lot of build failures
in Mesa drivers like

multiple definition of `syncobj_handle'; 
src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
 (symbol from plugin):(.text+0x0): first defined here
[  213s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':

I'm wondering if there is already anybody working on fixing these issues or is
it recommended to workaround it by setting -fcommon manually somehow? How can
the latter be done when using meson/ninja as build tool?

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev