Re: [certi-dev] Matlab Toolbox

[Eric Noulard]

2011/10/7 Jan-Patrick Osterloh <address@hidden>:
> Hi!
>
> --- Quoted from Christian Stenzel (Date: 29.09.2011 10:25): ---
>> Hello Jan,
>>
>> some good news.
>>
>> The Toolbox works also against the current CERTI CVS verison.
>> At first I didn't realize that some libary names have changed.
>>
>> Some more about that later.
>>
>> I have no idea about your fault description:
>>
>>> mex -v -DRTI_USES_STD_FSTREAM -D_GNU_SOURCE -o rti.mexglx rti/rti.cpp
>>> -lRTI-NG
>>> Undefined subroutine &Win32::GetShortPathName called
>>>  at /c/Programme/MATLAB/R2011a/bin/mex.pl line 127.
>>> BEGIN failed--compilation aborted
>>> at /c/Programme/MATLAB/R2011a/bin/mex.pl line 135.
>>> make: *** [rti.mexglx] Error 2
>
> I was finally able to fix this error. The problem was that the Win32 API
> is not part of the mingw distribution we use. I installed a Windows
> Perl, and now it works.
>
> After I fixed this, I had some problems with the mex script. In mingw
> the "%*" that is used in the script to forward all arguments of the
> script to the perl command does not work, it has to be a "$@" for me. I
> wonder why this script is needed at all. It would be probably better to
> define this in the makefile itself. The matlab folder could be set in
> the environment. Then, the -o argument was not accepted, for me it has
> to be -output. I attached a patch for that, maybe you can check it.
>
> Unfortunatly, I get now some compile errors:
> [...]
> gcc  -DRTI_USES_STD_FSTREAM -D_GNU_SOURCE -c -DMATLAB_MEX_FILE -x c++
> -oC:\DOKUME~1\PATRICK\LOKALE~1\TEMP\MEX_3C~1\rti.obj
> -IC:\PROGRA~1\MATLAB\R2010a\extern\include
> -IC:\PROGRA~1\MATLAB\R2010a\simulink\include -O3 -DMX_COMPAT_32 RTI\rti.cpp
>
> RTI\rti.cpp:38:23: fatal error: arpa/inet.h: No such file or directory
> compilation terminated.


May be this include file is only used for the ntohl/htonl function
(which usually are macro)?
Those are simple byte reordering functions:
http://linux.die.net/man/3/ntohl
they do exist on Windows too:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740069%28v=vs.85%29.aspx

Seems that MinGW expect to have those defined in winsock.h
https://bugzilla.mozilla.org/show_bug.cgi?id=411055



>> I only build the toolbox on Linux (g++). Obviously you are working on
>> a 32-bit Windows, correct? Your mex.pl file tries to call a function
>> it does not know. In Win32 Matlab comes only with an ANSI C compiler.
>> The Matlab-HLA-Tbx Wrapper file is a C++-File, therefore you need a
>> different system compiler. Please open Matlab and call mex -setup Try
>> to set the compiler options to mingw. But I'm not sure if Matlab
>> supports mingw. As a first step I would read the following
>> link:http://gnumex.sourceforge.net
>
> Hi, thanks for that. Yes, I'm working with Windows. This works perfectly
> (well, except the error above ;-))
>
>
>> The current Makefile in cvs uses old library names (libFedTime instead
>> libFedTimed and lRTI-NG instead lRTI-NGd). I will change that in cvs in
>> the near future.
> Hi, actually that is not correct. The "d" behind the name specifies that
> this is the debug version of CERTI.

This wouldn't solve the compilation error but may be you can try
to use CMake as well to compile the mex machiner
some people spoke about that topic recently on the CMake ML:
http://www.cmake.org/pipermail/cmake/2011-October/046555.html

> If you compile it in Release mode, the d is gone again. In order to do
> this, you have to set the CMAKE_BUILD_TYPE to "Release" I guess.
Yes this is the case.
Mangling the library name with a "d" for debug seems to be a widespread usage
to some of our users.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org