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

Tue Jul 21 03:47:29 UTC 2020

At the moment I'd like to generate the Visual Studio binaries. But, thanks
for the docker link.

On Mon, Jul 20, 2020 at 9:33 PM Matthew Waters <ystreet00 at gmail.com> wrote:

> 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>
> 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/20200720/30d67132/attachment-0001.htm>