Quantcast

cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Samuel Bryner
Hi,

I'm trying to cross-compile libftdi-1.1 with the MXE toolchain
(http://mxe.cc/, uses mingw32) and ran across two issues:

Cmake cannot find gettext() as it's in a separate library and not part
of libc. There's a TODO in the corresponding .cmake file
(cmake/FindLibintl.cmake) for this case but unfortunately I know nothing
of cmake to fix this properly. The following hack works though:

--- a/cmake/FindLibintl.cmake
+++ b/cmake/FindLibintl.cmake
@@ -34,6 +34,7 @@
   else (LIBINTL_LIBC_HAS_DGETTEXT)
     find_library(LIBINTL_LIBRARIES NAMES intl libintl )
     if(LIBINTL_LIBRARIES)
+      set(LIBINTL_LIBRARIES "-lintl -liconv")
       set(LIBINTL_LIB_FOUND TRUE)
     endif(LIBINTL_LIBRARIES)
   endif (LIBINTL_LIBC_HAS_DGETTEXT)

The other thing is that I didn't manage to compile the tests due to some
weird undefined references to boost_test:

Linking CXX executable test_libftdi1.exe
CMakeFiles/test_libftdi1.dir/objects.a(basic.obj):basic.cpp:(.text+0x21): undefined
reference to `_imp___ZTVN5boost9unit_test13test_observerE'
CMakeFiles/test_libftdi1.dir/objects.a(basic.obj):basic.cpp:(.text+0x7b): undefined
reference to
`_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
CMakeFiles/test_libftdi1.dir/objects.a(basic.obj):basic.cpp:(.text+0x198):
undefined reference to
`_imp___ZN5boost10test_tools9tt_detail10check_implERKNS0_16predicate_resultERKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEjNS1_10tool_levelENS1_10check_typeEjz'
/opt/mxe/usr/lib/gcc/i686-pc-mingw32/4.8.1/../../../../i686-pc-mingw32/bin/ld:
CMakeFiles/test_libftdi1.dir/objects.a(basic.obj): bad reloc address 0x2
in section
`.text$_ZN5boost6detail15sp_counted_baseD1Ev[__ZN5boost6detail15sp_counted_baseD1Ev]'
/opt/mxe/usr/lib/gcc/i686-pc-mingw32/4.8.1/../../../../i686-pc-mingw32/bin/ld:
final link failed: Invalid operation

I tried tracking this down but got nowhere. The only way I got libftdi
to compile was to disable the tests completely by removing
test/CMakeLists.txt.

Some additional information about my environment:

$ i686-pc-mingw32-gcc --version
i686-pc-mingw32-gcc (GCC) 4.8.1

Boost Version: 1.53.0
libusb: 1.0.18
libconfuse: 2.7

Cheers,
Sam



--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Xiaofan Chen
On Wed, Jun 11, 2014 at 11:28 PM, Samuel Bryner <[hidden email]> wrote:
> I'm trying to cross-compile libftdi-1.1 with the MXE toolchain
> (http://mxe.cc/, uses mingw32) and ran across two issues:
>
...
> The other thing is that I didn't manage to compile the tests due to some
> weird undefined references to boost_test:
>
> I tried tracking this down but got nowhere. The only way I got libftdi
> to compile was to disable the tests completely by removing
> test/CMakeLists.txt.

I do not use MXE and I do not use cross-compile either. I build
libftdi natively under Windows. But I agree it is not that easy to build the
unit test program (using Boost Unit Test Framework).

Did you build boost by yourself or using MXE or did you the the
Boost binary from somewhere from the Internet?

The only way I can build the test program is to build
Boost by myself (under Windows using MinGW/MSys).
When I use some ready-made toolchain like the one
from http://nuwen.net/mingw.html
I have similar problem like you when building the test program.

You can try my build here. But take note I was using
Boost 1.49 for this MinGW 32bit build. I have not
tried Boost 1.53.
http://sourceforge.net/projects/picusb/files/libftdi1-1.1_devkit_mingw32_12Feb2014.zip/download

I have another build using MinGW-w64 32/64bit toolchain
where I use the source of Boost 1.55 (but I did not have
the time to build the binary). In that case, I can build
the boost binding, but not the test program.
http://sourceforge.net/projects/picusb/files/libftdi1-1.1_devkit_x86_x64_21Feb2014.zip/download

--
Xiaofan

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Samuel Bryner
On 06/12/2014 07:04 AM, Xiaofan Chen wrote:

> On Wed, Jun 11, 2014 at 11:28 PM, Samuel Bryner <[hidden email]> wrote:
>> I'm trying to cross-compile libftdi-1.1 with the MXE toolchain
>> (http://mxe.cc/, uses mingw32) and ran across two issues:
>>
> ...
>> The other thing is that I didn't manage to compile the tests due to some
>> weird undefined references to boost_test:
>>
>> I tried tracking this down but got nowhere. The only way I got libftdi
>> to compile was to disable the tests completely by removing
>> test/CMakeLists.txt.
>
> I do not use MXE and I do not use cross-compile either. I build
> libftdi natively under Windows. But I agree it is not that easy to build the
> unit test program (using Boost Unit Test Framework).
>
> Did you build boost by yourself or using MXE or did you the the
> Boost binary from somewhere from the Internet?

I built boost using MXE so it should be the same as building it myself.
MXE builds everything from scratch.

>
> The only way I can build the test program is to build
> Boost by myself (under Windows using MinGW/MSys).
> When I use some ready-made toolchain like the one
> from http://nuwen.net/mingw.html
> I have similar problem like you when building the test program.

If this is a common problem, how about adding a cmake switch? Something
like -DBUILD_TESTS=OFF?

>
> You can try my build here. But take note I was using
> Boost 1.49 for this MinGW 32bit build. I have not
> tried Boost 1.53.
> http://sourceforge.net/projects/picusb/files/libftdi1-1.1_devkit_mingw32_12Feb2014.zip/download

Cool, I'll try that one out as well. Thanks!

>
> I have another build using MinGW-w64 32/64bit toolchain
> where I use the source of Boost 1.55 (but I did not have
> the time to build the binary). In that case, I can build
> the boost binding, but not the test program.
> http://sourceforge.net/projects/picusb/files/libftdi1-1.1_devkit_x86_x64_21Feb2014.zip/download
>


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Xiaofan Chen
On Thu, Jun 12, 2014 at 8:30 PM, Samuel Bryner <[hidden email]> wrote:

> On 06/12/2014 07:04 AM, Xiaofan Chen wrote:
>> I do not use MXE and I do not use cross-compile either. I build
>> libftdi natively under Windows. But I agree it is not that easy to build the
>> unit test program (using Boost Unit Test Framework).
>>
>> Did you build boost by yourself or using MXE or did you the the
>> Boost binary from somewhere from the Internet?
>
> I built boost using MXE so it should be the same as building
> it myself. MXE builds everything from scratch.

Yes I agree. I tried MXE under Mac OS X for a while but
later deleted it since I still prefer to build Windows
binary natively under Windows (and I can test them
immediately after the build). And I am not so sure
if you can really build the Windows Python bindings
under MXE.

Also I use Homebrew under Mac OS X and it
does not seem to support MXE very well.

>>
>> The only way I can build the test program is to build
>> Boost by myself (under Windows using MinGW/MSys).
>> When I use some ready-made toolchain like the one
>> from http://nuwen.net/mingw.html
>> I have similar problem like you when building the test program.
>
> If this is a common problem, how about adding a cmake switch? Something
> like -DBUILD_TESTS=OFF?

I am not so sure you can call it a common problem, so far
I do not see many people building the whole libftdi Windows
thingy (except me), most of the people only need the
C library and they are fine.

But still I think it is good to add the CMake switch now
at least you and I have this problem.

--
Xiaofan

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Thomas Jarosch
On Thursday, 12. June 2014 20:42:14 Xiaofan Chen wrote:

> > If this is a common problem, how about adding a cmake switch? Something
> > like -DBUILD_TESTS=OFF?
>
> I am not so sure you can call it a common problem, so far
> I do not see many people building the whole libftdi Windows
> thingy (except me), most of the people only need the
> C library and they are fine.
>
> But still I think it is good to add the CMake switch now
> at least you and I have this problem.

fine by me, too.

@Samuel: The "DOCUMENTATION" switch might provide
a good starting point for this.

Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Samuel Bryner
On 06/12/2014 02:56 PM, Thomas Jarosch wrote:

> On Thursday, 12. June 2014 20:42:14 Xiaofan Chen wrote:
>>> If this is a common problem, how about adding a cmake switch? Something
>>> like -DBUILD_TESTS=OFF?
>>
>> I am not so sure you can call it a common problem, so far
>> I do not see many people building the whole libftdi Windows
>> thingy (except me), most of the people only need the
>> C library and they are fine.
>>
>> But still I think it is good to add the CMake switch now
>> at least you and I have this problem.
>
> fine by me, too.
>
> @Samuel: The "DOCUMENTATION" switch might provide
> a good starting point for this.
Ok, I attached a small patch that adds a 'BUILD_TESTS' switch.
Do your rather want a pull request?

As for the cross-compiling: I switched to D2XX on Windows because I
don't want to incur the whole driver mess. Now I have to write
everything twice, but that's manageable.

Cheers,
Sam





--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

build_tests.git_patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Callback when data available to read?

Samuel Bryner
Hi,

Is there a way to get a callback when there is data available to read?

As far as I can see, you can either:

- poll ftdi_read_data()
- create a ftdi_transfer_control with ftdi_read_data_submit() and poll
that (with the additional drawback that you need to know the amount of
data you want to read beforehand)
- directly use libusb, defeating the point of libftdi somewhat.

This would be nice for asynchronous writes as well, maybe even with some
sort of intermediate progress callback.

ftdi_readstream() seems to go into the right direction but uses a
special synchronous FIFO mode.

Cheers,
Sam

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Callback when data available to read?

Rogier Wolff
On Thu, Jun 19, 2014 at 07:58:49PM +0200, Samuel Bryner wrote:

> Hi,
>
> Is there a way to get a callback when there is data available to read?
>
> As far as I can see, you can either:
>
> - poll ftdi_read_data()
> - create a ftdi_transfer_control with ftdi_read_data_submit() and poll
> that (with the additional drawback that you need to know the amount of
> data you want to read beforehand)
> - directly use libusb, defeating the point of libftdi somewhat.
>
> This would be nice for asynchronous writes as well, maybe even with some
> sort of intermediate progress callback.
>
> ftdi_readstream() seems to go into the right direction but uses a
> special synchronous FIFO mode.


I'd say: that'd be tricky to implement: your program "has control"
over the thread, and when it is not checking the FTDI chip, it's
simply not checking the FTDI chip! So the library would have to create
a separate thread and call your callback from the other thread, or
maybe something with signals, and then call your callback from the
signal.

Definitively not "trivial to add".

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Callback when data available to read?

Samuel Bryner
On 06/21/2014 01:08 PM, Rogier Wolff wrote:

> On Thu, Jun 19, 2014 at 07:58:49PM +0200, Samuel Bryner wrote:
>> Hi,
>>
>> Is there a way to get a callback when there is data available to read?
>>
>> As far as I can see, you can either:
>>
>> - poll ftdi_read_data()
>> - create a ftdi_transfer_control with ftdi_read_data_submit() and poll
>> that (with the additional drawback that you need to know the amount of
>> data you want to read beforehand)
>> - directly use libusb, defeating the point of libftdi somewhat.
>>
>> This would be nice for asynchronous writes as well, maybe even with some
>> sort of intermediate progress callback.
>>
>> ftdi_readstream() seems to go into the right direction but uses a
>> special synchronous FIFO mode.
>
>
> I'd say: that'd be tricky to implement: your program "has control"
> over the thread, and when it is not checking the FTDI chip, it's
> simply not checking the FTDI chip! So the library would have to create
> a separate thread and call your callback from the other thread, or
> maybe something with signals, and then call your callback from the
> signal.
>
> Definitively not "trivial to add".

Well, I'm already handing over control of handling asynchronous events
as described in [1], meaning I'm already using select() to wait for
libusb events.

The select() call actually returns when I have registered a read with
ftdi_read_data_submit() and I can receive data this way. But: select()
returns even when there's no data to read, reducing the whole thing to
simple polling. And I still have to manually reset the transfer_control
structure every time I receive something, because I'm not receiving a
fixed amount of bytes.

Basically, I'm trying to get it to work like a socket...

As for the implementation of such a feature: libusb already has
callbacks in place which libftdi uses to asynchronously receive data
('ftdi_read_data_cb()'). This callback could be extended to handle a
continuous stream of data and to call a user-defined function when it
received anything.

Regards,
Sam




[1] http://libusb.sourceforge.net/api-1.0/group__poll.html#polltime


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Thomas Jarosch
In reply to this post by Samuel Bryner
Hi Samuel,

On Thursday, 19. June 2014 13:32:17 Samuel Bryner wrote:
> > @Samuel: The "DOCUMENTATION" switch might provide
> > a good starting point for this.
>
> Ok, I attached a small patch that adds a 'BUILD_TESTS' switch.
> Do your rather want a pull request?

Patch applied, thanks :)

Cheers,
Thomas


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cross-compiling libftdi-1.1 with MinGW under Linux (MXE)

Samuel Bryner
Hi Thomas,

On 07/14/2014 04:29 PM, Thomas Jarosch wrote:
> Patch applied, thanks :)

Cool, thanks for the support!

Cheers,
Samuel


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Loading...