Cross compilation of GStreamer in Ubuntu docker container resulting in not all subprojects being built

Ben Rush ben at ben-rush.net
Sun Jul 19 16:11:24 UTC 2020


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> 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>
> 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>
>> 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 listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200719/1cf76c68/attachment.htm>


More information about the gstreamer-devel mailing list