Skip to content

Commit

Permalink
libvpx 1.14.0
Browse files Browse the repository at this point in the history
  • Loading branch information
totaam committed Jan 23, 2024
1 parent 6c2a2f9 commit 0a1a8d8
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions xpra-codecs.modules
Original file line number Diff line number Diff line change
Expand Up @@ -125,9 +125,9 @@
autogen-template="%(srcdir)s/%(autogen-sh)s --prefix=%(prefix)s %(autogenargs)s"
autogenargs="--enable-vp8 --enable-vp9 --enable-pic --enable-static --disable-install-docs --enable-realtime-only --enable-runtime-cpu-detect --disable-libyuv --disable-avx512 --disable-unit-tests"
autogen-sh="configure">
<branch module="webmproject/libvpx/archive/v1.13.1/libvpx-1.13.1.tar.gz"
version="1.13.1" checkoutdir="libvpx-1.13.1"
hash="sha256:00dae80465567272abd077f59355f95ac91d7809a2d3006f9ace2637dd429d14"
<branch module="webmproject/libvpx/archive/v1.14.0/libvpx-1.14.0.tar.gz"
version="1.14.0" checkoutdir="libvpx-1.14.0"
hash="sha256:5f21d2db27071c8a46f1725928a10227ae45c5cd1cad3727e4aafbe476e321fa"
repo="github.com"/>
<dependencies>
<dep package="yasm"/>
Expand Down

20 comments on commit 0a1a8d8

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI I found this commit doesn't build under GitHub runner arm64:

2024-02-09T17:51:16.8077420Z     [DEP] vp9/decoder/vp9_dsubexp.c.d
2024-02-09T17:51:16.8108290Z     [DEP] vp9/decoder/vp9_job_queue.c.d
2024-02-09T17:51:16.8129280Z     [DEP] vpx_config.c.d
2024-02-09T17:51:16.8470630Z     [DEP] vp9/ratectrl_rtc.cc.d
2024-02-09T17:51:16.8470990Z     [DEP] vp8/vp8_ratectrl_rtc.cc.d
2024-02-09T17:51:16.8712510Z In file included from /Users/runner/gtk/source/libvpx-1.14.0/vp9/ratectrl_rtc.cc:10:
2024-02-09T17:51:16.8713180Z In file included from /Users/runner/gtk/source/libvpx-1.14.0/vp9/ratectrl_rtc.h:14:
2024-02-09T17:51:16.8715460Z /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstdint:149:5: error: <cstdint> tried including <stdint.h> but didn't find libc++'s <stdint.h> header.           This usually means that your header search paths are not configured properly.           The header search paths should contain the C++ Standard Library headers before           any C Standard Library, and you are probably using compiler flags that make that           not be the case.
2024-02-09T17:51:16.8717590Z #   error <cstdint> tried including <stdint.h> but didn't find libc++'s <stdint.h> header. \
2024-02-09T17:51:16.8718000Z     ^

https://github.com/cpatulea/gtk-osx-build/actions/runs/7847269080/job/21415854218

It does build on my laptop (also arm64).

I'll keep looking at it and try to find a fix.

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/Users/runner/gtk/source/libvpx-1.13.1/configure --prefix=/Users/runner/gtk/inst --enable-vp8 --enable-vp9 --enable-pic --enable-static --disable-install-docs --enable-realtime-only --enable-runtime-cpu-detect --disable-libyuv --disable-avx512 --disable-unit-tests
...
Configuring for target 'generic-gnu'

vs

2024-02-09T17:51:10.6113240Z /Users/runner/gtk/source/libvpx-1.14.0/configure --prefix=/Users/runner/gtk/inst --enable-vp8 --enable-vp9 --enable-pic --enable-static --disable-install-docs --enable-realtime-only --enable-runtime-cpu-detect --disable-libyuv --disable-avx512 --disable-unit-tests 
...
2024-02-09T17:51:10.7030220Z Configuring for target 'arm64-darwin23-gcc'
2024-02-09T17:51:10.7097210Z   enabling arm64
2024-02-09T17:51:12.2911260Z   enabling neon
2024-02-09T17:51:12.2911590Z   enabling neon_dotprod
2024-02-09T17:51:12.2912370Z   enabling neon_i8mm
2024-02-09T17:51:12.2913380Z   enabling sve
2024-02-09T17:51:13.6467740Z   enabling webm_io

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CFLAGS / CXXFLAGS are set to:

-arch arm64 -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=12

looks like the culprit is this argument:

-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include

@cpatulea
Copy link

@cpatulea cpatulea commented on 0a1a8d8 Feb 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minimal repro:

$ cat test.cc
#include <cstdint>

g++  -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk test.cc
In file included from test.cc:1:
/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstdint:149:5: error: <cstdint> tried including <stdint.h> but didn't find libc++'s <stdint.h> header.           This usually means that your header search paths are not configured properly.           The header search paths should contain the C++ Standard Library headers before           any C Standard Library, and you are probably using compiler flags that make that           not be the case.
#   error <cstdint> tried including <stdint.h> but didn't find libc++'s <stdint.h> header. \
    ^
1 error generated.

I guess there's some conflict.. -I says to use the command-line tools, but -isysroot says to use Xcode

@cpatulea
Copy link

@cpatulea cpatulea commented on 0a1a8d8 Feb 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one gets picked up by jhbuild (https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/jhbuildrc-gtk-osx?ref_type=heads#L252):

bash-3.2$ xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

This one gets picked up by libvpx (https://github.com/webmproject/libvpx/blob/58731e2b7aed9b07c9b500e6dfa5eca04053e51d/build/make/configure.sh#L921):

bash-3.2$ xcrun --sdk macosx --show-sdk-path
/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk
# Even with SDKROOT=
bash-3.2$ SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk xcrun --sdk macosx --show-sdk-path
/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried dropping the jhbuild isysroot entirely:

    if sdkdir:
        #environ_prepend("LDFLAGS", "-L" + sdkdir + "/usr/lib")
        #environ_prepend("CFLAGS", "-I" + sdkdir + "/usr/include")
        #environ_prepend("CXXFLAGS", "-I" + sdkdir + "/usr/include")
        #environ_prepend("OBJCFLAGS", "-I" + sdkdir + "/usr/include")
        #environ_prepend("CPPFLAGS", "-I" + sdkdir + "/usr/include")
        environ_prepend("CMAKE_PREFIX_PATH", os.path.join(sdkdir, 'usr'), ':')
        environ_prepend("LIBRARY_PATH", sdkdir + "/usr/lib", ':')

everything build successfully (GitHub runner, arm64):

*** success *** [137/137]

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@totaam do you know why there are explicit -I${sdkdir}/usr/include?

I looked through history of gtk-osx, it was added here: https://gitlab.gnome.org/GNOME/gtk-osx/-/commit/76b3fc008983e9ac40e0fdeda6849550701e2d20 with comment:

# Seems like we need this since many libraries otherwise only look for
# various dependencies (e.g. libiconv) in /usr/lib, hence pulling in
# the wrong -L that doesn't have fat binaries on pre-10.5.

but it seems -isysroot should be sufficient, and indeed the build works (see above) without -I.

@totaam
Copy link
Collaborator Author

@totaam totaam commented on 0a1a8d8 Feb 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's from 15 years ago!
I think it's fair to assume that (most / all) of these libraries have been fixed since.

I think it's best to discuss this with upstream, @jralls will know more about this than we do.

@jralls
Copy link

@jralls jralls commented on 0a1a8d8 Feb 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That commit is from Richard Hult's efforts to create a framework bundle for the Gtk stack. It was an interesting idea, but it didn't really make sense in the days when autotools was the only show in town. Apple has done it for a few things--Python3 comes to mind--and it still doesn't work very well.

However it's true that jhbuildrc-gtk-osx sets both -[IL] ${sdkdir}/usr/(?:include|lib) and -isysroot ${sdkdir}. I added the -isysroot args in https://gitlab.gnome.org/GNOME/gtk-osx/-/commit/53e9916068a12ebd6657de3355a6c89157dbba56 with a note that they don't work on 10.4. I guess I should have removed the -I and -L bits from the flags when I dropped support for 10.4, but missed it.

I haven't seen the

In file included from test.cc:1:
/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstdint:149:5: error: <cstdint> tried including <stdint.h> but didn't find libc++'s <stdint.h> header. This usually means that your header search paths are not configured properly. The header search paths should contain the C++ Standard Library headers before any C Standard Library, and you are probably using compiler flags that make that not be the case.

error before. Kind of surprising that I haven't unless it's a new "feature" of libc++ that it has its own stdint.h that's different from .../usr/include/stdint.h (and I just did a diff, they're very different).

@cpatulea
Copy link

@cpatulea cpatulea commented on 0a1a8d8 Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jralls how would you feel about a patch like this: cpatulea@52dc697

Here's a GitHub action run showing the gtk-osx build succeeded in both x86_64 and arm64: https://github.com/cpatulea/gtk-osx-build/actions/runs/8147128260 (for arm64, the build itself succeeded, there was a failure only on an upload step at the end).

@jralls
Copy link

@jralls jralls commented on 0a1a8d8 Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cpatulea Not comfortable at all unless it works on older macOS/Xcode versions too. It should, but it needs to be tested with macOS 10.14 and the corresponding Xcode. I'm travelling and won't be able to do that for at least a month.

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused about your earlier message, you wrote:

I guess I should have removed the -I and -L bits from the flags when I dropped support for 10.4, but missed it.

I took this to mean you no longer intend to support 10.4.

Would you be able to clarify?

@totaam
Copy link
Collaborator Author

@totaam totaam commented on 0a1a8d8 Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cpatulea 10.4 vs 10.14!

@jralls
Copy link

@jralls jralls commented on 0a1a8d8 Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup. And when the macOS 15 beta drops after WWDC in June the minimum supported will be 10.15.

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, how about dropping -I/-L only for Mac OS >= 12: cpatulea@12b5d78

GitHub actions tests using Mac OS 12 and 14 so this shows the build works on those versions.

If this is still not acceptable, please let me know what path you would prefer. My goal is to get the Xpra gtk-osx-build working, under both Mac OS 12 and 14 (the GitHub actions environments), with latest package versions (libvpx 1.14.0). This is a preparation step for addressing some actual bugs in Xpra packaging for Mac OS (#27).

@jralls
Copy link

@jralls jralls commented on 0a1a8d8 Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about some patience? I'll be able to test on a 10.14 VM in April. Go ahead and submit your PR and I'll merge it after I've tested it.

You can of course in the meantime use your modified jhbuildrc-gtk-osx for your own debugging, or you can use the production one and override the flags settings in your jhbuildrc-custom.

@totaam
Copy link
Collaborator Author

@totaam totaam commented on 0a1a8d8 Mar 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cpatulea I'd happily take the change to drop -I/-L alone as xpra no longer supports MacOS < 12:

setup_sdk(target="12", sdk_version="12", architectures=["x86_64"])

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jralls sorry, did not mean to rush you. Will wait to hear back from you.

@totaam Great! Here's the PR: #39 Note it also requires changes to gtk-osx-setup.sh -- see the PR for details.

@jralls
Copy link

@jralls jralls commented on 0a1a8d8 Apr 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cpatulea
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thank you.

Please sign in to comment.