Re: [FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-31 Thread Michael Niedermayer
On Sat, Mar 07, 2020 at 10:32:53AM -0500, David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system.  With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host.  Drop the condition that aborts in
> this case, since a cross-compiler for an incompatible architecture
> will fail with -mtune=native anyway.
> 
> Signed-off-by: David Michael 
> ---
> 
> Hi,
> 
> I am building software in a ChromeOS-style environment where the native
> build system creates a cross-compiler with a different vendor string for
> each supported architecture, and cross-compiled packages are installed
> into their own root directory.  The build system's architecture is not
> handled any differently, so packages compatible with the native
> architecture are still technically being cross-compiled.
> 
> When I changed settings to tune for the native CPU so I can produce an
> installation optimized to run on the build system hardware, FFmpeg fails
> from this seemingly redundant test.  Can it just be dropped?
> 
> Thanks.
> 
> David
> 
>  configure | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 06e3a7b2a8..69ffdeb3ed 100755
> --- a/configure
> +++ b/configure
> @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
>  fi
>  
>  if test "$cpu" = host; then
> -enabled cross_compile &&
> -die "--cpu=host makes no sense when cross-compiling."
> -
>  case "$cc_type" in

I think that this should probably print a warning if the failure
is removed because its a odd combination that likely more often than not
is not what the user intended

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-30 Thread David Michael
On Mon, Mar 30, 2020 at 1:00 PM Derek Buitenhuis
 wrote:
> On 07/03/2020 15:32, David Michael wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build system.  With such a cross-compiler, it is still valid to
> > optimize builds with --cpu=host.  Drop the condition that aborts in
> > this case, since a cross-compiler for an incompatible architecture
> > will fail with -mtune=native anyway.
>
> Is there a reason you would set the cross-prefix instead of just the --cc, 
> etc.
> when compiling natively?

I want everything to use the cross-prefixed versions since those tools
are configured to build software in a sysroot using a different set of
compiler features than software in the minimal build root.  I am using
the same process as when cross-compiling OS images for other
incompatible architectures; configuring tuning for the build system's
CPU is just another valid use of this setup.

Thanks.

David
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-30 Thread Derek Buitenhuis
On 07/03/2020 15:32, David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system.  With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host.  Drop the condition that aborts in
> this case, since a cross-compiler for an incompatible architecture
> will fail with -mtune=native anyway.

Is there a reason you would set the cross-prefix instead of just the --cc, etc.
when compiling natively?

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-30 Thread David Michael
On Sun, Mar 22, 2020 at 11:01 PM David Michael  wrote:
> On Mon, Mar 16, 2020 at 9:16 AM David Michael  wrote:
> > On Sat, Mar 7, 2020 at 10:32 AM David Michael  wrote:
> > > Using a compiler with a different host triplet is considered
> > > cross-compiling, even when it is for the same architecture as the
> > > build system.  With such a cross-compiler, it is still valid to
> > > optimize builds with --cpu=host.  Drop the condition that aborts in
> > > this case, since a cross-compiler for an incompatible architecture
> > > will fail with -mtune=native anyway.
> > >
> > > Signed-off-by: David Michael 
> > > ---
> > >
> > > Hi,
> > >
> > > I am building software in a ChromeOS-style environment where the native
> > > build system creates a cross-compiler with a different vendor string for
> > > each supported architecture, and cross-compiled packages are installed
> > > into their own root directory.  The build system's architecture is not
> > > handled any differently, so packages compatible with the native
> > > architecture are still technically being cross-compiled.
> > >
> > > When I changed settings to tune for the native CPU so I can produce an
> > > installation optimized to run on the build system hardware, FFmpeg fails
> > > from this seemingly redundant test.  Can it just be dropped?
> > >
> > > Thanks.
> > >
> > > David
> > >
> > >  configure | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index 06e3a7b2a8..69ffdeb3ed 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
> > >  fi
> > >
> > >  if test "$cpu" = host; then
> > > -enabled cross_compile &&
> > > -die "--cpu=host makes no sense when cross-compiling."
> > > -
> > >  case "$cc_type" in
> > >  gcc|llvm_gcc)
> > >  check_native(){
> > > --
> > > 2.21.1
> >
> > Ping.
>
> Ping.

Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-22 Thread David Michael
On Mon, Mar 16, 2020 at 9:16 AM David Michael  wrote:
> On Sat, Mar 7, 2020 at 10:32 AM David Michael  wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build system.  With such a cross-compiler, it is still valid to
> > optimize builds with --cpu=host.  Drop the condition that aborts in
> > this case, since a cross-compiler for an incompatible architecture
> > will fail with -mtune=native anyway.
> >
> > Signed-off-by: David Michael 
> > ---
> >
> > Hi,
> >
> > I am building software in a ChromeOS-style environment where the native
> > build system creates a cross-compiler with a different vendor string for
> > each supported architecture, and cross-compiled packages are installed
> > into their own root directory.  The build system's architecture is not
> > handled any differently, so packages compatible with the native
> > architecture are still technically being cross-compiled.
> >
> > When I changed settings to tune for the native CPU so I can produce an
> > installation optimized to run on the build system hardware, FFmpeg fails
> > from this seemingly redundant test.  Can it just be dropped?
> >
> > Thanks.
> >
> > David
> >
> >  configure | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 06e3a7b2a8..69ffdeb3ed 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
> >  fi
> >
> >  if test "$cpu" = host; then
> > -enabled cross_compile &&
> > -die "--cpu=host makes no sense when cross-compiling."
> > -
> >  case "$cc_type" in
> >  gcc|llvm_gcc)
> >  check_native(){
> > --
> > 2.21.1
>
> Ping.

Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-16 Thread David Michael
On Sat, Mar 7, 2020 at 10:32 AM David Michael  wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system.  With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host.  Drop the condition that aborts in
> this case, since a cross-compiler for an incompatible architecture
> will fail with -mtune=native anyway.
>
> Signed-off-by: David Michael 
> ---
>
> Hi,
>
> I am building software in a ChromeOS-style environment where the native
> build system creates a cross-compiler with a different vendor string for
> each supported architecture, and cross-compiled packages are installed
> into their own root directory.  The build system's architecture is not
> handled any differently, so packages compatible with the native
> architecture are still technically being cross-compiled.
>
> When I changed settings to tune for the native CPU so I can produce an
> installation optimized to run on the build system hardware, FFmpeg fails
> from this seemingly redundant test.  Can it just be dropped?
>
> Thanks.
>
> David
>
>  configure | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/configure b/configure
> index 06e3a7b2a8..69ffdeb3ed 100755
> --- a/configure
> +++ b/configure
> @@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
>  fi
>
>  if test "$cpu" = host; then
> -enabled cross_compile &&
> -die "--cpu=host makes no sense when cross-compiling."
> -
>  case "$cc_type" in
>  gcc|llvm_gcc)
>  check_native(){
> --
> 2.21.1

Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] configure: Do not abort when cross-compiling to the native CPU

2020-03-07 Thread David Michael
Using a compiler with a different host triplet is considered
cross-compiling, even when it is for the same architecture as the
build system.  With such a cross-compiler, it is still valid to
optimize builds with --cpu=host.  Drop the condition that aborts in
this case, since a cross-compiler for an incompatible architecture
will fail with -mtune=native anyway.

Signed-off-by: David Michael 
---

Hi,

I am building software in a ChromeOS-style environment where the native
build system creates a cross-compiler with a different vendor string for
each supported architecture, and cross-compiled packages are installed
into their own root directory.  The build system's architecture is not
handled any differently, so packages compatible with the native
architecture are still technically being cross-compiled.

When I changed settings to tune for the native CPU so I can produce an
installation optimized to run on the build system hardware, FFmpeg fails
from this seemingly redundant test.  Can it just be dropped?

Thanks.

David

 configure | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configure b/configure
index 06e3a7b2a8..69ffdeb3ed 100755
--- a/configure
+++ b/configure
@@ -4785,9 +4785,6 @@ if test -n "$sysroot"; then
 fi
 
 if test "$cpu" = host; then
-enabled cross_compile &&
-die "--cpu=host makes no sense when cross-compiling."
-
 case "$cc_type" in
 gcc|llvm_gcc)
 check_native(){
-- 
2.21.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".