Cross compilation of GStreamer in Ubuntu docker container resulting in not all subprojects being built
Matthew Waters
ystreet00 at gmail.com
Tue Jul 21 02:33:25 UTC 2020
Yes, for non-linux platforms. It doesn't mean that gst-build can't do
it, just that gst-build requires more setup and is not as regularly
tested for this case :).
We do have a docker-based CI for the cross-mingw cases already that you
may want to borrow:
https://gitlab.freedesktop.org/gstreamer/gst-ci/-/blob/master/docker/cerbero/Dockerfile-fedora
and
https://gitlab.freedesktop.org/gstreamer/gst-ci/-/blob/master/gitlab/ci_template.yml#L896.
Cheers
-Matt
On 20/7/20 2:11 am, Ben Rush wrote:
> I see, so -- you technically do a lot of your dev work using cerbero
> too? You're the expert, so I'll follow your lead.
>
> FYI: once I get this working and am able to do a cross-compile build
> of all the components (and in particular, webrtcbin), I'm going to
> respond to this thread with my dockerfile so that it's reproducible
> for posterity's sake.
>
> Cheers.
>
> On Sun, Jul 19, 2020 at 10:51 AM Matthew Waters <ystreet00 at gmail.com
> <mailto:ystreet00 at gmail.com>> wrote:
>
> That's cool! We'd love to see those improvements/suggestions.
>
> It is possible to develop with cerbero however the required steps
> are a little bit more involved.
>
> For branches that track git (all GStreamer recipes and some
> others), what I personally do is push a branch to the cerbero
> local sources of the specific project (on linux by default is at
> '$HOME/.cache/cerbero-sources/$project'). './cerbero-uninstalled
> show-config' will tell you exactly where.
>
> Then either, change the branch in the recipe, or add a
> '$HOME/.cerbero/cerbero.cfg' file (python syntax) with something
> like the following (where the values are a git commit reference,
> branch names in this case).
>
> ```
> recipes_commits = {
> # "libusrsctp" : "hang-fix",
> "gst-plugins-base-1.0" : "egl-display-debug-cat",
> # "gstreamer-1.0" : "fail",
> "gst-plugins-bad-1.0" : "amcvideodec-gl-sync-meta-copy",
> # "gst-validate" : "android",
> # "gst-editing-services-1.0" : "android",
> }
> ```
>
> For tarball-based sources, creating a patch in the local sources
> directory and then adding the patch to the recipe is usually the
> goto move.
>
> Cheers
> -Matt
>
> On 20/7/20 1:33 am, Ben Rush wrote:
>> Thanks. I will take a look at your suggestions.
>>
>> On the Cerbero v. meson front: my company relies on windows a
>> lot, and so I'm doing a lot of use of GStreamer on Windows. I've
>> got a lot of suggestions / tweaks / etc. that I'd love to be able
>> to contribute to the project to better help people such as myself
>> who are doing things exclusively on Windows. It's my
>> understanding that cerbero is best for building what's in master,
>> but that if I want to do any sort of rapid iteration / testing,
>> meson is the route to go. So, that's my driving force.
>>
>> And thanks again, mate. Your work on everything is appreciated by
>> a lot of people.
>>
>> On Sun, Jul 19, 2020 at 10:21 AM Matthew Waters
>> <ystreet00 at gmail.com <mailto:ystreet00 at gmail.com>> wrote:
>>
>> You also need to be careful with constructing all of the
>> necessary paths and environment variables so that no system
>> libraries are found and that your custom build versions are
>> found instead.
>> https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/master/cerbero/config.py#L450
>> contains a non-exhaustive list. There are also
>> platform-specific configurations that may modify some of
>> those values: e.g. for windows:
>> https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/master/config/windows.config
>> and then there may be recipe-specific workarounds, e.g. for
>> openssl:
>> https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/master/recipes/openssl.recipe#L150.
>>
>> Generally we would recommend the cerbero route as it tries
>> takes care of all of this for you. If something doesn't
>> work, we can attempt to fix it.
>>
>> On 20/7/20 1:05 am, Ben Rush wrote:
>>> I see, yes. That's a distinct possibility given the fact my
>>> docker container has libnice-dev, which made it in on
>>> accident. However, what's odd is that I did do a cross build
>>> of openssl as part of the docker container. Is this not enough?
>>>
>>> RUN git clone https://github.com/openssl/openssl.git && \
>>> cd openssl && \
>>> ./Configure --cross-compile-prefix=x86_64-w64-mingw32-
>>> mingw64 && \
>>> make && \
>>> make install
>>>
>>> All of this ran before any of the output I mentioned above.
>>>
>>> On Sun, Jul 19, 2020 at 10:03 AM Matthew Waters
>>> <ystreet00 at gmail.com <mailto:ystreet00 at gmail.com>> wrote:
>>>
>>> You need to have a cross-build of openssl or gnutls to
>>> be able to build libnice.
>>>
>>> I assume that the 'pkg-config --version openssl' is only
>>> showing you the system versions which would be built for
>>> linux, not mingw.
>>>
>>> On 20/7/20 12:16 am, Ben Rush wrote:
>>>> In particular, I'm having trouble getting the webrtc
>>>> library to build, and it appears as though -- if I
>>>> track it back far enough -- the issue is with libnice.
>>>> The meson build output results in the output at the end
>>>> of this email (I'll defer posting it now to make the
>>>> email reading easier).
>>>>
>>>> According to the error, the problem is that pkg-config
>>>> is unable to find openssl. But running this at the
>>>> command prompt (after attaching to the container),
>>>> results in what appears to be a positive for finding
>>>> openssl:
>>>>
>>>> root at b5f46e708137:/gst-build# pkg-config --version openssl
>>>> 0.29.1
>>>>
>>>> Ultimately I'm curious if someone has been able to
>>>> build webrtc and the like cross compiled for Windows
>>>> from Ubuntu, etc. I'd love to have a nice, dockerized
>>>> system for building for Windows but after about day of
>>>> fighting, I've yet to get it to work completely.
>>>>
>>>> Here is the output:
>>>>
>>>> |Executing subproject libnice method meson
>>>> |
>>>> |Project name: libnice
>>>> |Project version: 0.1.17.1
>>>> |C compiler for the build machine: cc (gcc 7.5.0 "cc
>>>> (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0")
>>>> |C linker for the build machine: cc ld.bfd 2.30
>>>> |C compiler for the host machine:
>>>> x86_64-w64-mingw32-gcc (gcc 7.3.0
>>>> "x86_64-w64-mingw32-gcc (GCC) 7.3-win32 20180312")
>>>> |C linker for the host machine: x86_64-w64-mingw32-gcc
>>>> ld.bfd 2.30
>>>> |Library iphlpapi found: YES
>>>> |Library ws2_32 found: YES
>>>> |Checking for function "clock_gettime" : NO (cached)
>>>> |Library rt found: NO
>>>> |Checking for function "clock_gettime" with dependency
>>>> -lrt: NO (cached)
>>>> |Has header "arpa/inet.h" : NO (cached)
>>>> |Has header "net/in.h" : NO
>>>> |Has header "netdb.h" : NO (cached)
>>>> |Has header "ifaddrs.h" : NO
>>>> |Has header "unistd.h" : YES (cached)
>>>> |Checking for function "poll" : NO (cached)
>>>> |Checking for function "getifaddrs" : NO
>>>> |Compiler for C supports arguments
>>>> -fno-strict-aliasing: YES
>>>> |Message: warning level: 1
>>>> |Message: werror enabled: false
>>>> |Dependency gio-2.0 found: YES 2.62.6 (cached)
>>>> |Dependency (anonymous) from subproject
>>>> subprojects/glib found: YES 2.62.6
>>>> |Dependency (anonymous) from subproject
>>>> subprojects/glib found: YES 2.62.6
>>>> |Dependency (anonymous) from subproject
>>>> subprojects/glib found: YES 2.62.6
>>>> |Dependency gthread-2.0 from subproject
>>>> subprojects/glib found: YES 2.62.6
>>>> |Message: Crypto library requested: auto
>>>> |Run-time dependency gnutls found: NO (tried pkgconfig
>>>> and cmake)
>>>> |Run-time dependency openssl found: NO (tried pkgconfig
>>>> and cmake)
>>>> |Looking for a fallback subproject for the dependency
>>>> openssl
>>>> |Subproject directory not found and openssl.wrap file
>>>> not found
>>>> |Subproject subprojects/openssl is buildable: NO
>>>> (disabling)
>>>> |Dependency openssl from subproject subprojects/openssl
>>>> found: NO
>>>> |Library crypto found: NO
>>>> |Library eay32 found: NO
>>>> |
>>>> |subprojects/libnice/meson.build:249:4: Exception:
>>>> Problem encountered: Either GnuTLS or OpenSSL is
>>>> required as crypto library, but neither was found
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200721/cd41e1c5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200721/cd41e1c5/attachment-0001.sig>
More information about the gstreamer-devel
mailing list