unable to cross compile (mingw) for windows

[mkrufky]

unable to cross compile (mingw) for windows

[rdp]

some official downloadable binaries might be nice too but cross compiling works for me for now thanks so much!

[mkrufky]

@rdp official downloadable windows binaries sound like a great idea, but I don't currently know how to build libdvbtee under windows without using your scripts. I was thinking of taking a closer look at your scripts, hack them a bit to only build libdvbtee and then run it in my CircleCI or AppVeyor accounts to automatically post binaries to github, but it will be a while before I find the time to figure all of that out... Do you know of any simpler solutions?

[rdp]

(it's like a pthread port to windows). That is weird, you should also have ./sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/include/pthread.h (nuking the sandbox and trying again doesn't fix it? how are you invoking the script exactly?) I did get it to build just now if you just want a binary: https://sourceforge.net/projects/ffmpegwindowsbi/files/random_builds/?upload_just_completed=true

[phillipbarnett]

No, I just have these three copies;
phillip@sandbender:~/Downloads/ffmpeg-windows-build-helpers/sandbox$ find -name pthread.h -print
./cross_compilers/pkgs/gcc/source/gcc-7.1.0/fixincludes/tests/base/sys/pthread.h
./cross_compilers/pkgs/gcc/source/gcc-7.1.0/fixincludes/tests/base/pthread.h
./cross_compilers/source/mingw-w64-5.0.2/mingw-w64-libraries/winpthreads/include/pthread.h

Nuking the sandbox seemed to do the trick though, I ran the (slightly modified) script afterwards and it all ran through and compiled correctly. I now have a windows executable of dvbtee, and also of ffmpeg, which I've never succeeded in building for Windows yet, so that's absolutely great. Thanks for this highly useful tool, and the help!

[mkrufky]

I don't have access to a windows build environment, but I do have an appveyor account and will try to bring up a windows build on the https://github.com/mkrufky/libdvbtee/commits/win branch.

I don't know exactly how to build using automake in windows... Again, if only I had a windows box handy here I'd probably figure it out. Can you tell me what (open source, hopefully) tools I should download and what commands to execute in order to replicate the build under windows, and I'll debug the build failure from there? I've read a bit about msys - is that what you're using?

[rdp]

you can get free windows vm's here:
https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/

In actuality I was using a cross building environment, though I assume the
compilation results would be the same:

https://github.com/rdp/ffmpeg-windows-build-helpers

re-add this line to have it attempt to build it:

rdp/ffmpeg-windows-build-helpers@a756ff0

FWIW.
-roger-

On Sat, Jan 16, 2016 at 9:38 AM, Michael Ira Krufky <
[email protected]> wrote:

I don't have access to a windows build environment, but I do have an
appveyor account and will try to bring up a windows build on the
http://github.com/mkrufky/libdvbtee/tree/win
https://github.com/mkrufky/libdvbtee/tree/win branch.

I don't know exactly how to build using automake in windows... Again, if
only I had a windows box handy here I'd probably figure it out. Can you
tell me what (open source, hopefully) tools I should download and what
commands to execute in order to replicate the build under windows? I've
read a bit about msys - is that what you're using?

—
Reply to this email directly or view it on GitHub
#12 (comment).

[mkrufky]

@rdp , thanks for this great info! I had no idea these windows VMs were available - I will give them a try.

I took a look at your https://github.com/rdp/ffmpeg-windows-build-helpers project and it looks very helpful. Very easy to use for cross building windows applications on a Linux machine.

I made some minor fixes to my code and build system, some of which I have already merged into the master branch. I used your rdp/ffmpeg-windows-build-helpers@ce2bf07 and after some additional hacks that can be found on the https://github.com/mkrufky/libdvbtee/commits/win branch, I got as far as it all building fine but with some linker errors:

libtool: link: i686-w64-mingw32-g++ -I../../libdvbtee -I../../libdvbtee_server -g -O2 -o dvbtee-parser.exe parser.o  -L../../libdvbtee -L../../libdvbtee_server -L./decode -L../value ffmpeg-windows-build-helpers/sandbox/win32/libdvbtee/libdvbtee_server/.libs/libdvbtee_server.a -L../libdvbtee ffmpeg-windows-build-helpers/sandbox/win32/libdvbtee/libdvbtee/.libs/libdvbtee.a ffmpeg-windows-build-helpers/sandbox/win32/libdvbtee/libdvbtee/decode/.libs/libdvbtee_decode.a ffmpeg-windows-build-helpers/sandbox/win32/libdvbtee/libdvbtee/value/.libs/libvalueobj.a ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/libiconv.a -lws2_32 ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/libdvbpsi.a -pthread
ffmpeg-windows-build-helpers/sandbox/win32/libdvbtee/libdvbtee/.libs/libdvbtee.a(functions.o): In function `mkgmtime':
ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/include/time.h:220: undefined reference to `_mkgmtime32'
ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/include/time.h:220: undefined reference to `_mkgmtime32'
collect2: error: ld returned 1 exit status
Makefile:394: recipe for target 'dvbtee-parser.exe' failed
make[3]: *** [dvbtee-parser.exe] Error 1

...I'm currently looking into how to resolve those. I'm pretty sure it's just a matter of some missing links to some libraries, although I haven't dealt with this under windows until now. If you have any ideas, patches welcome :-) Otherwise, I hope to resolve it soon.

[mkrufky]

Aha! I've gotten my win branch to build using your rdp/ffmpeg-windows-build-helpers@ce2bf07 !

Can you test it for me? Here's how:

Re-run your build again. When it fails, do:

(for win32)

cd sandbox/win32/libdvbtee
git remote update
git pull . origin/win
cd ../../..

(for win64)

cd sandbox/x86_64/libdvbtee
git remote update
git pull . origin/win
cd ../../..

...and then re-run your build once more. This time, libdvbtee should build without error.

In the meanwhile, I'll work on turning these hacks into proper fixes...

[mkrufky]

libdvbtee will build with additional features enabled if you add libcurl and libhdhomerun as libraries in your dependency list.

[rdp]

awesome, will test...

[rdp]

Awesome, builds great. I was wondering if there's a way to use the tool to
extract EPG info from TS dumps, ex:
https://trac.ffmpeg.org/raw-attachment/ticket/3025/sbs.2.5M.ts
https://www.google.com/url?q=https%3A%2F%2Ftrac.ffmpeg.org%2Fattachment%2Fticket%2F3025%2Fsbs.2.5M.ts&sa=D&sntz=1&usg=AFQjCNHL1OMH8xY4aboz28aiV6paCWQEiQ
I tried a few command line options
dvbtee.exe -E -j -Fsbs.2.5M.ts
hoping it would be able to extract EPG browsing info from the TS file (I
believe there is some in there anyway, DVBInspector seems to show some.
Thanks so much for your support, let me know when it gets merged into
master so I can update my scripts, awesome!

On Mon, Jan 18, 2016 at 8:45 PM, Michael Ira Krufky <
[email protected]> wrote:

libdvbtee will build with additional features enabled if you add libcurl
and libhdhomerun as libraries in your dependency list.

—
Reply to this email directly or view it on GitHub
#12 (comment).

[mkrufky]

Thanks for the feedback! With the help of those Windows VMs that you have pointed to above, I've managed to test dvbtee.exe under Windows and found many bugs, most of which I fixed last night. It must have been before you tried it out, because the state of things was very bad beforehand. There are still three outstanding problems that I am aware of:

• cannot read data from STDIN
• cannot read more than 4k from a local file (this is why you're not getting all of the info that you're expecting from the sbs2.5M.ts file as you've mentioned)
• cannot read from TCP / UDP

These problems only occur in the windows build, and I plan to work a bit more on it today. I should have it all fixed in a matter of days :-)

I noticed that you added the libcurl dependency -- thanks for that. If you could also add libhdhomerun as I mentioned earlier, it would make it a lot more functional and make it way easier for me to do my testing. You can download source code here: http://www.silicondust.com/support/downloads/linux
or binaries here:
http://www.silicondust.com/support/downloads

(The linux source code tarball also contains the windows source)

[mkrufky]

The "abort read from a local file after 4k" issue is fixed now in the win branch, but there is another problem preventing the EPG to be read from the sbs.2.5M.ts file: for some reason, the descriptor decoder submodules are not being linked in the cross build environment. If you test the same file under linux, the EPG shows up. I am still looking into this.

[mkrufky]

...and now there's a hack in place that forces the descriptor decoders to link. I need to think of something better... but it's there in the win branch for testing in the meanwhile. The windows version should behave the same as the linux version does now when reading local files. @rdp can you try again and let me know if the EPG data that you're expecting is showing up now?

[mkrufky]

...winsock network input & output is working now, too. The only things that I haven't fixed yet is read from STDIN and server mode

[rdp]

Working great thank you! Finally command line EPG data LOL.
Let me know when the win branch is merged in (and answer that superuser)
and I'll accept your answer there, thanks so much for your help here.
-roger-

On Wed, Jan 27, 2016 at 6:58 AM, Michael Ira Krufky <
[email protected]> wrote:

...winsock network input & output is working now, too. The only think that
I haven't fixed yet is read from STDIN

—
Reply to this email directly or view it on GitHub
#12 (comment).

[rdp]

I made an attempt at cross compiling libhdhomerun but somehow wasn't able
to quite get it working. I may revisit it at some point or if you have any
feedback there, fire away. Thanks again.
-roger-

On Wed, Jan 27, 2016 at 12:11 PM, Roger Pack [email protected] wrote:

Working great thank you! Finally command line EPG data LOL.
Let me know when the win branch is merged in (and answer that superuser)
and I'll accept your answer there, thanks so much for your help here.
-roger-

On Wed, Jan 27, 2016 at 6:58 AM, Michael Ira Krufky <
[email protected]> wrote:

...winsock network input & output is working now, too. The only think
that I haven't fixed yet is read from STDIN

—
Reply to this email directly or view it on GitHub
#12 (comment).

[mkrufky]

rdp all the fixes you need have been merged into the master branch. Please update your scripts accordingly. Thanks again for shipping dvbtee with your cross-build, and for testing my fixes here. I'll take a crack at fixing the libhdhomerun cross build, and I'll send you a PR if I have any success.

[rdp]

Shoot nothing comes to mind.
Like I said, there's no rush since I can cross compile it locally :0

On Fri, Jun 3, 2016 at 5:06 AM, Michael Ira Krufky <[email protected]

wrote:

@rdp https://github.com/rdp official downloadable windows binaries
sound like a great idea, but I don't currently know how to build libdvbtee
under windows without using your scripts. I was thinking of taking a closer
look at your scripts, hack them a bit to only build libdvbtee and then
run it in my CircleCI or AppVeyor accounts to automatically post binaries
to github, but it will be a while before I find the time to figure all of
that out... Do you know of any simpler solutions?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAw0HntPpVPZPXnItEjU6jf2ci89mCkks5qIAqhgaJpZM4HGIyG
.

[phillipbarnett]

Hi! Sorry to revive an old thread, but I'm keen to try dvbtee and can't find a Windows binary.

Firstly - this looks like a great tool for cross compiling - but I'm having difficulties getting libdvbtee to compile for Win64. After fixing a few moved repositories etc I've managed to get through as far as starting to compile a windows 64 build, but it errors with 'fatal error - pthreads errors. I'm using Ubuntu 17.10 and gcc 7.2.0
Error reproduced below. Any ideas how to fix pthreads?
Thanks in advance

x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../.. -D_FILE_OFFSET_BITS=64 -DDVBPSI_DIST -mtune=generic -O3 -Wall -std=gnu99 -D_GNU_SOURCE -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wshadow -Waggregate-return -Wmissing-prototypes -Wnested-externs -Wsign-compare -Wno-cast-qual -DDVBPSI_DIST -MT dvbinfo-buffer.o -MD -MP -MF .deps/dvbinfo-buffer.Tpo -c -o dvbinfo-buffer.o test -f 'buffer.c' || echo './'buffer.c
buffer.c:27:10: fatal error: pthread.h: No such file or directory
#include <pthread.h>
^~~~~~~~~~~
compilation terminated.
Makefile:423: recipe for target 'dvbinfo-buffer.o' failed
make[3]: *** [dvbinfo-buffer.o] Error 1
make[3]: *** Waiting for unfinished jobs....
dvbinfo.c:46:10: fatal error: pthread.h: No such file or directory
#include <pthread.h>
^~~~~~~~~~~
compilation terminated.
Makefile:395: recipe for target 'dvbinfo-dvbinfo.o' failed
make[3]: *** [dvbinfo-dvbinfo.o] Error 1

[rdp]

Do you have the file pthread.h anywhere in your sandbox?

On Tuesday, April 17, 2018, phillipbarnett ***@***.***> wrote: Hi! Sorry to revive an old thread, but I'm keen to try dvbtee and can't

find a Windows binary.

Firstly - this looks like a great tool for cross compiling - but I'm

having difficulties getting libdvbtee to compile for Win64. After fixing a few moved repositories etc I've managed to get through as far as starting to compile a windows 64 build, but it errors with 'fatal error - pthreads errors. I'm using Ubuntu 17.10 and gcc 7.2.0

Error reproduced below. Any ideas how to fix pthreads? Thanks in advance x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../.. -D_FILE_OFFSET_BITS=64

-DDVBPSI_DIST -mtune=generic -O3 -Wall -std=gnu99 -D_GNU_SOURCE -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wshadow -Waggregate-return -Wmissing-prototypes -Wnested-externs -Wsign-compare -Wno-cast-qual -DDVBPSI_DIST -MT dvbinfo-buffer.o -MD -MP -MF .deps/dvbinfo-buffer.Tpo -c -o dvbinfo-buffer.o test -f 'buffer.c' || echo './'buffer.c

buffer.c:27:10: fatal error: pthread.h: No such file or directory #include <pthread.h> ^~~~~~~~~~~ compilation terminated. Makefile:423: recipe for target 'dvbinfo-buffer.o' failed make[3]: *** [dvbinfo-buffer.o] Error 1 make[3]: *** Waiting for unfinished jobs.... dvbinfo.c:46:10: fatal error: pthread.h: No such file or directory #include <pthread.h> ^~~~~~~~~~~ compilation terminated. Makefile:395: recipe for target 'dvbinfo-dvbinfo.o' failed make[3]: *** [dvbinfo-dvbinfo.o] Error 1 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.<

https://ci4.googleusercontent.com/proxy/YNCGiXVZGk4uFEWNfOfh222HWQ4m5vLUD_FCMWe0hUibfbcJiWObbgUTCW01lXLjhNuA25CcPSdwz85qHoOls6JdTQNKa3Y05WGlmTyWEoQfRXLVEjubNeClquqQBnEC7cvHc9dLGNX_yvaGaNUvfaUIE8gdOQ=s0-d-e1-ft#https://github.com/notifications/beacon/AAAw0Gn_EVMzfkU_y8qFUrcBuqKmjfqjks5tpcCmgaJpZM4HGIyG.gif>

[phillipbarnett]

Hi,
Yes, pthrads.h shows up here, which looks sensible to me.
sandbox/cross_compilers/source/mingw-w64-5.0.2/mingw-w64-libraries/winpthreads/include/pthread.h
But surely this is just for compiling with posix threads, for Linux? I want to compile for Win64. (Well, actually I've been able to compile a linux executable, and am experimenting with that, as that's my preferred platform anyway - I just wanted to see if I could get a Windows version as I thought I might have to produce a Windows solution for work, but actually I think I'll be able to use Linux instead. Would still be nice to see what i'm doing wrong though ...
Thanks

[hak-foo]

I was curious if "read from STDIN" works in Windows now. I've been able to successfully pipe in a chunk of video stream on Linux to pull the data of interest, but the cross-compiled version in Windows just reports "failed to open stdin!" If I save the chunk to disc and then pass "-Ffilename" that works, but I'd prefer to avoid creating the temp file and burning through SSD write cycles.

[mkrufky]

@hak-foo This issue was resolved and closed over seven years ago, and your recent comment has no relation to it at all.

PLEASE DO NOT REPLY ON THIS OR ANY OTHER EXISTING ISSUE THREADS.

Your message has been "hidden" - If you'd like to report a new issue, please create a new issue.