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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ben Rush
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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters
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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters
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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Rush
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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters
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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Rush
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 <[hidden email]> 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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters
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 <[hidden email]> 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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel




_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Rush
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel




_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters
Ah, then that requires a windows native build.  That cannot currently be cross-compiled from linux.

Cheers
-Matt

On 21/7/20 1:47 pm, Ben Rush wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel





_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Rush
Yeah, my hope was that I could build individual binaries via mingw that I could test by dropping into the MSVC binaries folder. It appears aa though various interdependencies are preventing that. I'm all honesty, I'd rather build from Linux if possible, that was my goal. But that's just not the case. 

I'll focus on building from Windows for this particular goal of mine (though I still intend to build from source for Linux, just not for my day job). 

On Mon, Jul 20, 2020, 11:27 PM Matthew Waters <[hidden email]> wrote:
Ah, then that requires a windows native build.  That cannot currently be cross-compiled from linux.

Cheers
-Matt

On 21/7/20 1:47 pm, Ben Rush wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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? 

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 <[hidden email]> 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@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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel





_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel