Build mmbtools on Windows
Alex To
Is there anyone successfully build mmbtools (crc-dabmux) on Windows?
Anyone could give me some hint on what tools used to build ? I read
that it is built on Windows but so far couldn't seem to find any
documentation about the tool chain to use.
Thank you very much
Alex
Rashid Mustapha
was on a stand there that I saw Francois running it on a laptop with Windows
2000 therefore I am sure it can be done...
Sorry I don't have any further details.
Rash.
Pascal Charest
cases. One was used for a commercial software-based DMB encoder. The
second one was a DRM receiver as you can see on this youtube clip:
http://www.youtube.com/user/crcmmb#p/u/8/ocAfPtDZEHc
Another demo was working on a MacBook computer. A virtual machine was
used for running the mmbTools live CD, another for the Windows DMB
encoder and a last one running Linux for the OpenMokast receiver. So,
everything was running on a MacBook with the help of virtual machines!
For curious, here is a youtube clip with an example of this system
(without the DMB encoder)
http://www.youtube.com/user/crcmmb#p/u/3/8IuDTn4-DIg
Pascal
Rashid Mustapha wrote:
> I recall (I'm sure I didn't dream this!) that at IBC a number of years
> ago when I
> was on a stand there that I saw Francois running it on a laptop with
> Windows
> 2000 therefore I am sure it can be done...
>
> Sorry I don't have any further details.
>
> Rash.
>
> On 9 August 2011 13:14, Alex To <tonh...@gmail.com
Pascal Charest
> I think I got it. Downloaded Cygwin and build fine
>
Hello Alex,
Good news! You got time to find a working solution before I can answer.
Thank you very much for reporting it (your success, I mean ;-) )
Here is some additional background. A few years ago, crc-dabmux code was
developed to cross-compile with MinGW (compilation on Linux to obtain a
Windows executable). It is not the case anymore as we don't test on
Windows, but the coding approach have not changed much since that time
and only minor adjustments might be needed. The alternative is, as you
found it, to use Cygwin.
Thank you again,
Pascal
Alex To
Cgywin but I hit an error which I overlooked. Therefore, I deleted the
post to avoid confusion. Look like building on Windows for the latest
release isn't supported any more.
Pascal Charest
Visual Studio or Dev-C++ ? There is no specific Linux library used in
the code, only standards such as IEEE POSIX. Usually, these API are
available for most compiler. The main problem that I've usually got is
that these APIs do not work the same for all implementations.
Otherwise, you can still give a try to cross-compilation. In the past,
I've installed MinGW using RPM packages on Opensuse. But here is some
additional instructions that I've used in the past for building the
cross-compiler from source:
http://wiki.wxwidgets.org/Install_The_Mingw_Cross-Compiler
To compile I've used this command (or something like that): ./configure
--prefix=/usr/local/i586-mingw32 --host=i586-mingw32msvc
Here are some additional informations that I've used:
http://wiki.wxwidgets.org/Cross-Compiling_Under_Linux
This is the only information that I can give you as we do not work
anymore since many years with Windows for many mmbtools projects.
Another alternative is to use virtual machines. I've used VMWare in the
past and now using VirtualBox. Other might be good, but I didn't try
them. I run mmbtools in a VM in Linux. Indeed, it is very convenient as
I can work on many systems simultaneously. Sometimes I have a working
system and I do my tests on another VM. Once I'm satisfied, I replace
the working system with the one that I was testing. I can even work with
snapshot. If I've done something wrong with a system, I can go back to
the last snapshot.
Regards,
Pascal
Alex To
Thank you very much for sharing the information.
Our company use VMware extensively though but the purpose is more to
make mmbtools work on Windows since we have custom applications
developed for Windows platform.
I am trying to compile it with Visual Studio and will definitely share
the instructions here once I'm done.
Best regards
Alex
Rashid Mustapha
I'm not so sure about how stable it will be in a VM though - good luck with that.
I found I had the least trouble running on decent hardware with a bare-metal OS!
R.
Alex To
number of compilation errors (related to checking for malloc(),
pthread, winsock etc..) but now it comes to FEC.
I talked to mr. Phil Karn on messenger but he has no idea about
Windows as he is not using Windows but he heard other people ported
his code to Windows before.
Thank you and I look forwards to hearing from you
Regards
Alex To
sorry, I have no idea how the first part in my previous email
disappeared.
I wanted to ask in my previous email, how did you cross compile FEC
library written by mr Phil Karn.
Thank you
Regards
Alex
Pascal Charest
The cross-compiler is not anymore installed on my computer so I can't
test the following procedure, but it should work.
Use the libfec source code on our website, there is some modification to
enable cross-compilation. In the README, follow the procedure for other
Linux, but add the --host=i586-mingw32msvc option to ./configure. The
'i586-mingw32msvc' might differ depending of the installed version of
the cross-compiler.
Here is the detailed procedure (- instructions, > command to run):
- download libfec from http://mmbtools.crc.ca/content/view/39/65/
> tar xzf fec_3.0.1-2.src.tar.gz
> tar xzf fec_3.0.1.orig.tar.gz
> zcat fec_3.0.1-?.diff.gz | patch -p0
> cd fec-3.0.1/
> autoreconf --install
> ./configure --prefix=/usr/local/i586-mingw32 --host=i586-mingw32msvc
> make
> make install
This should install libfec on your Linux system in the cross-compiler
directory. This will enable access to the library when compiling
crc-dabmux. Make sure that the prefix (cross-compiler) path is the right
one.
If it doesn't work, try something like that:
> find . -name \*.dll
- copy the dll in the right cross-compiler directory
- copy fec.h in the cross-compiler directory
For crc-dabmux, the configure operation also needs --host option. This
will add additional includes for winsock and pthread.
I hope it will help you,
Pascal
--
Pascal Charest
Research Engineer Ingénieur en recherche
Communications Research Centre Centre de recherches sur
Canada les communications Canada
3701 Carling Ave. 3701, avenue Carling
PO Box 11490, Station H CP 11490, succursale H
Ottawa, Ontario Ottawa, Ontario
Canada K2H 8S2 Canada K2H 8S2
Tel: (613) 998-2479 Tél.: (613) 998-2479
Fax: (613) 993-9950 Téléc.: (613) 993-9950
Email: pascal....@crc.ca Cour.: pascal....@crc.ca
Web site: www.crc.ca Site web: www.crc.ca
Government of Canada Gouvernement du Canada
Alex To
I installed successfully on Ubuntu and was trying to compile for
Windows
I followed the following steps to compile on Ubuntu 11.04 (x64) with
gcc and everything is fine
> > tar xzf fec_3.0.1-2.src.tar.gz
> > tar xzf fec_3.0.1.orig.tar.gz
> > zcat fec_3.0.1-?.diff.gz | patch -p0
> > cd fec-3.0.1/
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/
bin/ld: cannot find -lc
I heard Mingw doesn't come with libc but libfec does link to libc:
$(CC) -shared -Xlinker -soname=$(SO_NAME) -o $@ -Wl,-whole-archive $^ -
Wl,-no-whole-archive -lc -lm (extract from makefile)
How would I fix the link to libc ??
Thank you
Regards
Alex
> Hello Alex,
>
> The cross-compiler is not anymore installed on my computer so I can't
> test the following procedure, but it should work.
>
> Use the libfec source code on our website, there is some modification to
> enable cross-compilation. In the README, follow the procedure for other
> Linux, but add the --host=i586-mingw32msvc option to ./configure. The
> 'i586-mingw32msvc' might differ depending of the installed version of
> the cross-compiler.
>
> Here is the detailed procedure (- instructions, > command to run):
Alex To
seem to add additional include for winsock and pthread so I downloaded
pthread for Win32 at
http://sourceware.org/pthreads-win32/
After that I cross compiled pthread, copy header to Mingw include
folder, pthread.a file to Mingw Lib folder, pthread.dll file to Mingw
Bin folder and the compiler doesn't complain about missing pthread
anymore.
Alex
Alex To
May I know what is the Linux distribution you used to cross-compile
FEC last time? and did you build Mingw from source or install from the
distribution repo?
I have tried Ubuntu 11.04 (x86_x64 & x86), 10.04 (x86)
I install Mingw, Wine, libtool from the repo the I followed the steps
mentioned about several times but still the compiler complain about
missing libc.
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/
bin/ld: cannot find -lc
of libc. When you compile FEC how did you resolve the complain about
libc?
I thought the steps should be very straight forward but I can't seem
to figure out yet how my build environment different from yours.
Regards
Alex
Pascal Charest
I returned to my 'old' Opensuse 10.0 and compared the source code with
the current version of libfec. I think that I found a solution!
I changed something in the makefile to enable cross-compilation of 32
and 64 Linux system, but I broke cross-compilation for Windows. As it is
not tested and used anymore, I did not checked it. There is a wrong
linker command, libc should not be used.
* Edit file makefile.in
** For the line following "# for Linux et al"
** Change "$(SHARED_LIBS)" with "libfec.so"
* run autoreconf
* run ./configure --host=...cross...
* make
It should work now. The next line with DLLTOOL will be called instead of
SHARED_LIBS.. It is the line that I have added when I wanted to
cross-compile.
Regards,
Pascal
Alex To wrote:
> Dear Mr. Pascal
>
> May I know what is the Linux distribution you used to cross-compile
> FEC last time? and did you build Mingw from source or install from the
> distribution repo?
>
> I have tried Ubuntu 11.04 (x86_x64& x86), 10.04 (x86)
Alex To
Mr. Pascal, thank you very much, I have successfully compiled FEC and
CRCDAB_MUX on Windows and obtained CRC-DabMux.exe and CRC-
BridgeTest.exe
Build environment:
Linux Ubuntu LTS 10.04 x86
Mingw32 from the Repo
I) Compile FEC
To compile FEC, I did the instruction Pascal mentioned in the earlier
post with additional tweaks as follows:
* Edit file makefile.in
** For the line "all: libfec.a $(SHARED_LIB)"
** Change "$(SHARED_LIBS)" with "libfec.dll"
** For the line "install -m 644 -p $(SHARED_LIBS) libfec.a @libdir@"
** Change "$(SHARED_LIBS)" with "libfec.dll"
** Comment the line (cd @libdir@;ln -f -s $(SHARED_LIB) libfec.so) as
I do not need to make any symbolic link,
* run make distclean
* run autoreconf
* run ./configure --prefix=/usr/i586-mingw32msvc --host=i586-
mingw32msvc --build=i686-linux
* Note that if you build on Linux x64, --build should be x86_64-linux
* make
II) Compile CRC_DabMux
1) Cross compile libpthread
Read here http://clam-project.org/wiki/Devel/Windows_MinGW_cross_compile#pthreads
However, I followed the instructions provided with a bit of
modification to suit my build environment
After the line "make CROSS=i586-mingw32msvc- GC-inlined", do the
following instead
** cp libpthreadGC2.a /usr/i586-mingw32msvc/lib
** cp *.h /usr/i586-mingw32msvc/include
** cp pthreadGC2.dll /usr/i586-mingw32msvc/bin
** ln -s libpthreadGC2.a /usr/i586-mingw32msvc/lib/libpthread.a
Reason is in my system, Mingw32 is installed in /usr/i586-mingw32msvc
2) Cross compile CRC_DabMux
The compilation is a bit tricky (at least for me as I was never a
Linux developer, I don't even know Makefile and stuff before and all I
know is Visual Studio)
The version of CRC_DabMux as of the date of writing is 0.3.0.4
Go ahead with normal cross-compile procedure
** ./configure --prefix=/usr/i586-mingw32msvc --host=i586-mingw32msvc
--build=i686-linux
** make
If you got compilation error, the followings are the errors I face
when I compile
a) " ::malloc has not been declared"
Read this http://nerdland.net/unstumping-the-internet/malloc-has-not-been-declared/
<-- this helped me to understand the problem
However, in the end, I decided to put a quick fix and do these:
** open configure.ac
** comment AC_FUNC_MALLOC and AC_FUNC_REALLOC
I am not sure if this will cause unpredictable behaviors
b) "pragma is not allowed here" in dabInputPacketFile.cpp line 50
I just comment line 50: /*# pragma pack(pop) */
Again, I am not sure if this will cause unpredictable behaviors
c) "O_NONBLOCK is not defined in dabInputRawFifo.cpp"
I added #define O_NONBLOCK 0 after
#ifndef _WIN32
# define O_BINARY 0
#endif
so it becomes
#ifndef _WIN32
# define O_BINARY 0
#endif
#define O_NONBLOCK 0
d) Link to libws32_32
** open src/Makefile.in
** Find CRC_BridgeTest_LDADD = $(LDADD)
** Change it to CRC_BridgeTest_LDADD = $(LDADD) -lws2_32
** Find CRC_DabMux_LDADD = $(FEC_LIBS) -lpthread
** Change it to CRC_DabMux_LDADD = $(FEC_LIBS) -lpthread -lws2_32
If some one here know why the compiler complains about "pragma is not
allowed here" in b), I'd love to hear from you. I commented that line
to get pass the compiler but I believe that is not the way to solve.
If you face any other errors, let me know, probably I have come across
it but I forgot to put it here.
If anyone interested in getting the Windows binaries, just email me
and I can post it some where or email to you.
Regards
Alex
Pascal Charest
added a link to this thread in our documentation section of mmbTools.
http://mmbtools.crc.ca/content/view/35/61/
Pascal
Alex To
However, I do not know if the 2 workarounds in my tutorial will cause
unpredictable behaviors. The 2 workarounds are
1. Comment AC_FUNC_MALLOC and AC_FUNC_REALLOC to bypass checking for
GNU compatible malloc and realloc
http://nerdland.net/unstumping-the-internet/malloc-has-not-been-declared/
2. "pragma is not allowed here" in dabInputPacketFile.cpp line 50
I commented the line /* pragma pack(pop) */ to temporarily bypass the
complain. At the meantime I am reading about what this line does and
probably we need a proper fix for this.
Any suggest are welcome
Best regards
Alex
Pascal Charest
validate that the system can compile these function. I did not add
replecament functions in case these tests failed, but as long as the
code compiles, that should be fine.
Fix 2: this migth introduces unpredictable behaviour as without it,
bitfield structure will be padded to be aligned to 32 bits or 64 bits.
The file Eti.h shows how to solve this problem.
Pascal
Alex To
how Windows and Linux handle packing specifiers for structs with the
following references:
http://en.wikipedia.org/wiki/Data_structure_alignment
http://stackoverflow.com/questions/1537964/visual-c-equivalent-of-gccs-attribute-packed
http://www.linuxquestions.org/questions/programming-9/whats-this-__attribute__-packed-193570/
For those who come across the code in fix 2 and have no idea what is
it about, read the above links and you should be fine. I didn't
understand too due to my limited knowledge of C/C++ :(
Dear Mr. Pascal
Would you shed some light whether my understanding is correct?
In the fie dabInputPacketFile.cpp, line 36 to 54:
#ifdef _WIN32
# pragma pack(push, 1)
#endif
struct packetHeader {
unsigned char addressHigh:2;
unsigned char last:1;
unsigned char first:1;
unsigned char continuityIndex:2;
unsigned char packetLength:2;
unsigned char addressLow;
unsigned char dataLength:7;
unsigned char command;
}
#ifdef _WIN32
# pragma pack(pop)
#else
__attribute((packed))
#endif
; // <--------- this is a comma at line 54
Because of the comma that ends the struct, compiling for Windows will
not work because #pragma pack(pop) can't be in between of the struct
and the comma. So I have replaced the code from ln 36 to 54 with the
followings:
#ifdef _WIN32
# pragma pack(push, 1)
#endif
struct packetHeader {
unsigned char addressHigh:2;
unsigned char last:1;
unsigned char first:1;
unsigned char continuityIndex:2;
unsigned char packetLength:2;
unsigned char addressLow;
unsigned char dataLength:7;
unsigned char command;
}
#ifndef _WIN32
__attribute((packed))
#endif
;
#ifdef _WIN32
# pragma pack(pop)
#endif
Another workaround I think should work is to replace the line 36 to 54
with the following alternative:
struct packetHeader {
unsigned char addressHigh:2;
unsigned char last:1;
unsigned char first:1;
unsigned char continuityIndex:2;
unsigned char packetLength:2;
unsigned char addressLow;
unsigned char dataLength:7;
unsigned char command;
} PACKED; // <-- use the definition of PACKED from Eti.h
#ifdef _WIN32
# pragma pack(pop)
#endif
Please suggest of I am doing anything wrong here
Thank you very much
Best regards
Alex To
On Aug 19, 10:54 pm, Pascal Charest <pascal.char...@crc.ca> wrote:
> Fix 1: this is not a problem as long as it compile. This is a check to
> validate that the system can compile these function. I did not add
> replecament functions in case these tests failed, but as long as the
> code compiles, that should be fine.
>
> Fix 2: this migth introduces unpredictable behaviour as without it,
> bitfield structure will be padded to be aligned to 32 bits or 64 bits.
> The file Eti.h shows how to solve this problem.
>
> Pascal
>
>
>
>
>
>
>
> Alex To wrote:
> > No problem at all Mr. Pascal
>
> > However, I do not know if the 2 workarounds in my tutorial will cause
> > unpredictable behaviors. The 2 workarounds are
>
> > 1. Comment AC_FUNC_MALLOC and AC_FUNC_REALLOC to bypass checking for
> > GNU compatible malloc and realloc
Pascal Charest
Indeed, the pack(pop) instruction was at the wrong place. Both of your
suggestions seem fine. I personally prefer the second as it is clearer,
but at after the macro expansion, it will be identical to the first one.
Note that the pack(pop) instruction is not required. However, it is
better to use it as it return to the default byte alignment for the rest
of the code for a better efficiency.
Pascal