Closed ElectricRCAircraftGuy closed 6 years ago
ElectricRCAircraftGuy
commented
9 years ago Update: I have the library running on Windows 8.1 just fine now, though I don't think this is a complete solution. I just copied and pasted the "libserialport.h" and "serialport.c" files into my working project directory, and it all compiles and runs just fine. I'm using Code::Blocks, running a C++ Console Project.
Spork-Schivago
commented
9 years ago Just so I understand you correctly, you didn't actually compile the library into a DLL? You just copied the header file libserialport.h and the main source file, serialport.c into your working project directory and you're compiling and linking them directly into your project? Instead of passing a -lserialport to the linker and having a libserialport.dll file somewheres, is that correct?
ElectricRCAircraftGuy
commented
9 years ago Yes, that's correct. Honestly, I have no idea how to use C++ libraries in the common way or do static or dynamic linking. No idea how to independently compile a library, etc etc. I need to learn those things so if you learn them please feel free to teach me.
But...meanwhile, I just copied those two source code files into my CodeBlocks project, then went to Project --> Add Files to add them to my project, and voila! It works. I thought that might work....and it does.
For clarity, I am using #include "libserialport.h" of course too.
Spork-Schivago
commented
9 years ago Well, I believe libserialport is a C library, not a C++ library. I believe there's something called libserial that is a C++ library. According to the instructions located on the project's main website
http://sigrok.org/wiki/Libserialport
In Windows, once you have your MSYS setup correctly, inside the shell, just change to where you downloaded the src and:
$ ./autogen.sh
$ ./configure
$ make
$ sudo make installthe $'s aren't supposed to be typed. They represent a non-root (super user) account's prompt. So, lets say I'm in Windows and I'm at the MSYS prompt. I've properly setup everything, I've downloaded git and have it installed in MSYS, I have Autotools installed, like automake, etc. I can download the src code by running git:
git clone git://sigrok.org/libserialportThen I cd into the directory,
cd libserialportThen I type
./autogen.shThat should create libserialport.h and a few other files. Then I run configure,
./configureand that will configure the Makefile for my system, my setup. After this, I just need to compile the library. To do this, I type
makeIf everything went fine and there's no error messages, I should have a dll now. To install, I can type
sudo make installThis will install the various files (ie, the header file, the dll, and perhaps a pkg-config file) into the proper directories. Then, in code::blocks (I don't have much experience with this) I find the configuration options for my project and I look for a place that says something about libraries...because I don't have the experience using code::blocks, but perhaps you might click on Projects and then Build options? Then you might want to click on Linker Settings and there might be an area that says something like Link libraries. There should be away to add the library you just compiled and installed in this area.
I can't really get libserialport to compile though. I'm using MSYS 1.0 and MinGW-w64 (32-bit and 64-bit). MSYS doesn't seem to have libtool installed and I can't figure out how to get it installed. So when ever I try to run autogen, it fails. Even if I try under MSYS 2, autogen completes but again, when I make, linking fails. I've asked for help from the MinGW-w64 people on help installing libtool. I've also asked for help on the mailing list for libserialport to see if they have any suggestions with MSYS 2. Good luck with everything.
Again though, just want to stress, I really don't know anything about code::blocks so the process I described might be completely wrong. I think just copying the header file and the source file like you've done might cause problems later on down the road. I dunno. I don't really know how libraries work really.
ElectricRCAircraftGuy
commented
9 years ago Hey thanks again for the info. I'll go through it more thoroughly when I get the chance, and try it all out. Meanwhile, I'm writing code to send serial data to my Arduino now.
I have used ~50+ libraries in the past, but all in the Arduino IDE, and all open-source. I've also written about a dozen C++ Arduino libraries, using .h header files and .cpp source files. Due to the open-source nature of every library I've ever used, I've never done dynamic linking or used a precompiled library before. Nevertheless, I have some understanding of how libraries work...at least when using them as source code directly.
What I've done shouldn't cause any problem whatsoever that I'm aware of. The only downside is that I have to copy and paste these two files into every project I want to use them in, or I have to use a full absolute or relative path in my include statement every time I call them.
Ex: Instead of
#include <libserialport.h>
I have to use
#include "..\..\libraries\libserialport.h"
(a relative path, goes up 2 directories, then down into "libraries," then finds the .h file.)
or a full path like
#include "C:\dev\Cpp\practice_and_test\serial_practice\libraries\libserialport.h"
should work too.
I've also spent ~ 4 hrs today reading the .h and .c source files for this library. It's definitely a C, not a C++ library, but that doesn't mean you can't use it in your C++ code. They included a special #ifdef as follows to ensure linking is done correctly if you use this library in your C++ code:
#ifdef __cplusplus
extern "C" {
#endif(lines 83-85 of libserialport.h)
So, for now I'm going to keep plugging away at my code to get something working with my Arduino comms. It's taken me days just to get to this point......
ElectricRCAircraftGuy
commented
9 years ago hold on...making more edits above...markdown syntax is screwing up my formatting and erasing stuff I'm writing....
Spork-Schivago
commented
9 years ago I wish you the best of luck, keep us posted. I didn't mean to imply that the library couldn't be used with C++ code. I just wanted to make sure you knew the library was written in C.
I believe a static library is when you compile the C code into object code and then just add the object code to an archive using ar. I think people tend to run ranlib or something on the object before doing this. With dynamic though, I believe you link them into a library instead of just dealing with the object files.
For me, I don't have a libserialport.h file. I have a libserialport.h.in file and after running a command like autogen, I believe it should create the libserialport.h file.
The only reason I question whether you'd have problems or not is because I notice there's a few other source files, windows.c, freebsd.c, linux.c, linux_termios.c, macosx.c. I would think each one would be used based on what OS you're on. For example, in Linux, I can successfully compile the library by doing what I described above, no problems, and it uses the linux.c and linux_termios.c source files I believe. In Windows, I believe windows.c would be used. I see in windows.c a function called: get_root_hub_name.
I wonder where you got the libserialport.h file without running the autogen.sh script and I wonder if you can use the functions like get_root_hub_name. Perhaps libserialport.c contains some of the functions available in the library, but not all of them?
Granted, if you were successfully able to generate the header file, I would adding the individual source files to project would work just fine. It's not the "proper" way (if there is such a thing) but being open source, with the license they're using, I believe you're allowed to use libserialport in anyway you want. For me, I kinda need the library for what I'm doing because I'm compiling my code for at least three different systems (at least Linux 64-bit, perhaps 32-bit as well, Windows 64-bit and Windows 32-bit). For this, I need to use three separate compilers and having three compiled libraries would make things great.
ElectricRCAircraftGuy
commented
9 years ago ah....interesting...you're right:
"For me, I don't have a libserialport.h file. I have a libserialport.h.in file and after running a command like autogen, I believe it should create the libserialport.h file."
I just noticed that. I actually didn't download the library here on github, I got it here: http://sigrok.org/wiki/Downloads --> libserialport-0.1.0.tar.gz. It has the .h file.
Weird stuff. So much I don't know.
If you get the libserialport download above, and just include the .h and .c files, including the extra couple for linux, I bet it will work with source files alone. I've checked in the header files and source files and they extensively use #includes and #ifdef type compiler directives to ensure you get the right files for Windows vs Linux. I think you can do it all with just the source, like I did. If you can't get it to work the proper way, you might give that a try....
Notice the download I reference above, however, is v0.1.0. This github repo is v0.1.1 I think, and v0.1.1 has a few extra things as I've read through the documentation.
ElectricRCAircraftGuy
commented
9 years ago I just did some looking at the libserialport.h.in file. I don't know what the .in at the end means, but if you just delete the .in from the file extension, you have the .h header file all there with no other changes required. I also see a bunch of functions at the top that are for version 0.1.1 only.
ElectricRCAircraftGuy
commented
9 years ago Alright, I'm looking back at your detailed MSYS instructions. ./autogen.sh doesn't work.
$ ./autogen.sh Generating build system... ./autogen.sh: line 44: libtoolize: command not found
I don't think I have the autotools; automake, etc....I'm looking for those.
ElectricRCAircraftGuy
commented
9 years ago Ok...I found this: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
This command looks close enough. I'm running it now...installing a bunch of stuff (~450mB worth).
pacman -Sy git tar binutils autoconf make libtool automake python2 p7zip patch gcc docbook-xsl
ElectricRCAircraftGuy
commented
9 years ago Ok, the installations above went ok.
Now, ./configure seems to have failed at the end, and "make" didn't work.
Here's my output:
Gabriel@gabriel-Toshiba MINGW64 /c/dev/Cpp/libraries/libserialport-0.1.1
$ ./autogen.sh
Generating build system...
configure.ac:43: installing 'autostuff/ar-lib'
configure.ac:43: installing 'autostuff/compile'
configure.ac:41: installing 'autostuff/missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing 'autostuff/depcomp'
Gabriel@gabriel-Toshiba MINGW64 /c/dev/Cpp/libraries/libserialport-0.1.1
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... no, using cp -pR
checking build system type... x86_64-pc-mingw64
checking host system type... x86_64-pc-mingw64
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/x86_64-pc-msys/bin/ld.exe
checking if the linker (/usr/x86_64-pc-msys/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 8192
checking how to convert x86_64-pc-mingw64 file names to x86_64-pc-mingw64 format... func_convert_file_msys_to_w32
checking how to convert x86_64-pc-mingw64 file names to toolchain format... func_convert_file_msys_to_w32
checking for /usr/x86_64-pc-msys/bin/ld.exe option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/x86_64-pc-msys/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
./configure: line 13018: syntax error near unexpected token `0.22'
./configure: line 13018:`PKG_PROG_PKG_CONFIG(0.22)'
Gabriel@gabriel-Toshiba MINGW64 /c/dev/Cpp/libraries/libserialport-0.1.1
$ make
make: **\* No targets specified and no makefile found. Stop.
......I'm stuck.....
ElectricRCAircraftGuy
commented
9 years ago PS. Here's the libtool installation you needed:
$ pacman -Sy libtool
Spork-Schivago
commented
9 years ago I use MSYS 1.0. We don't have pacman. I got mine working. The problem was with MinGW-w64, by default, it wants to install in C:\Program Files\mingw-w64... and C:\Program Files (x86)\mingw-w64... which libtool doesn't like (along with some other things). I can't help much with MSYS2 because I don't use it. I'd suggest perhaps making sure you have pkg-config installed. From the sounds of it, you might not. Figure out what package includes pkg-config and install it.
pacman -S
To compile in MSYS1, I wrote a text file on how to do it. It's a little off but I could fix that later if you decide you want to try via MSYS1. In MSYS1, you need to download a few programs and install them (which I provide instructions for on how to do so in my text file). It assumes you have a fresh system with nothing, no MSYS, no MinGW, no git, nothing, and it walks ya through my steps. Everything seems to work fine once I get the compiled libraries installed.
On my system, keep in mind, I'm compiling for both 32-bit and 64-bit. If you're only needing the 64-bit version of the 32-bit version, the instructions would be cut in half.
If you want to continue with your MSYS2, I'd suggest trying to find the pkg-config program. In MSYS 1, I would check for it like this:
where pkg-configto see if it's installed. In Linux, I would check lke this:
which pkg-configto see if it was installed. Sorry it took so long to get back to ya. I had to compile autoconf, automake and libtool, along with uninstall my two mingw-w64 installations and reinstall them and install git (for Windows). Once all that was taken care of, everything went nice and smooth.
Spork-Schivago
commented
9 years ago I have updated my instructions if you're interested. They're for MSYS 1.0 though. I'm sure you could adapt them if you wanted to. They assume you have no compiler, nothing, and they go from downloading MSYS, MinGW-w64, etc all the way to distributing the DLL when you compile your programs and hand them out to customer. Just let me know if you want them.
ElectricRCAircraftGuy
commented
9 years ago Yes please; I'd appreciate having them. Feel free to email me at ercaguy[special email symbol]gmail[dot]com.
By the way, in one of our discussions you mentioned not seeing all the functions in the .c file. Well, I found them; they are all there in the serialport.c file.
Here's all the "missing" functions:
enum sp_return spset##x(struct sp_port port, type x) { \ struct port_data data; \ struct sp_port_config config; \ TRACE("%p, %d", port, x); \ CHECK_OPEN_PORT(); \ TRY(get_config(port, &data, &config)); \ config.x = x; \ TRY(set_config(port, &data, &config)); \ RETURN_OK(); \ } \ enum sp_return sp_getconfig##x(const struct sp_port_config config, type x) { \ TRACE("%p, %p", config, x); \ if (!config) \ RETURN_ERROR(SP_ERR_ARG, "Null config"); \ x = config->x; \ RETURN_OK(); \ } \ enum sp_return sp_setconfig##x(struct sp_port_config *config, type x) { \ TRACE("%p, %d", config, x); \ if (!config) \ RETURN_ERROR(SP_ERR_ARG, "Null config"); \ config->x = x; \ RETURN_OK(); \ }
The ## symbol is a special macro operator. See here: http://www.cprogramming.com/reference/preprocessor/token-pasting-operator.html.
So, the above code defines all functions with names "spset...", "sp_getconfig...", and "sp_setconfig...". It's a really tricky way to define all of those all at once, since all they are doing is accessing the respective element within the opaque structures, via the -> operator.
Spork-Schivago
commented
9 years ago I don't fully understand the library because I haven't had time to really sit down and study it yet. I've just glanced, however, I would think the fact that they have the extra source files, like windows.c, linux.c, they're actually needed for one reason or another. I know when I compile the library, they do get compiled into the library, depending on what OS I'm on. Compiling in Linux gets the linux.c file and linux_termios.c file or whatever it was compiled into the library. Compiling in Windows gets windows.c compiled into the library. I sent the e-mail. Good luck.
ElectricRCAircraftGuy
commented
9 years ago Hey thanks. I know you're right about those files being needed for the 0.1.1 version (or the Linux version of the 0.1.0 version); I just don't know what they do yet either. At the moment I'm using the 0.1.0 version still, on Windows, since I got it to work with the one .h and .c source file without any special "building" of the library. I'll check the email. Thanks.
Spork-Schivago
commented
9 years ago The instructions I provide tell you to download and install Git for Windows. That's needed for grabbing the 0.1.1 version of the library. You could probably skip that if you wanted to continue to use the 0.1.0 library, however, generally, with programs that have such a low version number, even a small revision increase can provide huge improvements.
I've talked to the people on the sigrok mailing list (who provide support for libserialport). I highly doubt we'll see any example code for libserialport until it becomes more mature. It's very new still and has a good way to go. The reason I'm using it is because I need a library that provides serial port communication in Linux and Windows without me needing to have separate code for the various OSes and the fact that I need a library in C, not C++.
For the most part, if you need help with libserialport and you try contacting them, they might not be able to provide as detailed help as what's in the file I sent you. To really use it, you have to read the code and get a full understanding of how it all works. It uses pointers a lot, that's not really my strong point. I've been reading up on them though so I can really get a good understanding of the code.
On Thu, Sep 3, 2015 at 11:04 PM, Gabriel Staples notifications@github.com wrote:
Hey thanks. I know you're right about those files being needed; I just don't know what they do yet either. At the moment I'm using the 0.1.0 version still since I got it to work with the one .h and .c source file without any special "building" of the library. I'll check the email. Thanks.
— Reply to this email directly or view it on GitHub https://github.com/martinling/libserialport/issues/10#issuecomment-137636107 .
Spork-Schivago
commented
9 years ago Just wanted to know if you ever got the library to compile successfully. If so, perhaps you could close this issue so the developers don't have it listed as a bug with their code? If not, maybe I could help you more via e-mail.
menesty
commented
7 years ago Hi, I have the same problem, can't build project under windows. I have install msys2 checkout project from git $ ./autogen.sh #pass without errors $ ./configure #pass without errors
$ make make all-am
CC serialport.lo
serialport.c: In function ‘sp_blocking_write’:
serialport.c:785:2: error: unknown type name ‘fd_set’
fd_set fds;
^~~~~~
serialport.c:795:3: warning: implicit declaration of function ‘timeradd’ [-Wimpl icit-function-declaration]
timeradd(&start, &delta, &end);
^~~~~~~~
serialport.c:798:2: warning: implicit declaration of function ‘FD_ZERO’ [-Wimpli cit-function-declaration]
FD_ZERO(&fds);
^~~~~~~
serialport.c:799:2: warning: implicit declaration of function ‘FD_SET’ [-Wimplic it-function-declaration]
FD_SET(port->fd, &fds);
^~~~~~
serialport.c:810:8: warning: implicit declaration of function ‘timercmp’ [-Wimpl icit-function-declaration]
if (timercmp(&now, &end, >))
^~~~~~~~
serialport.c:810:29: error: expected expression before ‘>’ token
if (timercmp(&now, &end, >))
^
serialport.c:813:4: warning: implicit declaration of function ‘timersub’ [-Wimpl icit-function-declaration]
timersub(&end, &now, &delta);
^~~~~~~~
serialport.c:815:12: warning: implicit declaration of function ‘select’ [-Wimpli cit-function-declaration]
result = select(port->fd + 1, NULL, &fds, NULL, timeout_ms ? &delta : NULL);
^~~~~~
serialport.c: In function ‘sp_blocking_read’:
serialport.c:1011:2: error: unknown type name ‘fd_set’
fd_set fds;
^~~~~~
serialport.c:1036:29: error: expected expression before ‘>’ token
if (timercmp(&now, &end, >))
^
serialport.c: In function ‘sp_blocking_read_next’:
serialport.c:1148:2: error: unknown type name ‘fd_set’
fd_set fds;
^~~~~~
serialport.c:1173:29: error: expected expression before ‘>’ token
if (timercmp(&now, &end, >))
^
serialport.c: In function ‘sp_output_waiting’:
serialport.c:1308:22: error: ‘TIOCOUTQ’ undeclared (first use in this function)
if (ioctl(port->fd, TIOCOUTQ, &bytes_waiting) < 0)
^~~~~~~~
serialport.c:1308:22: note: each undeclared identifier is reported only once for each function it appears in
serialport.c: In function ‘sp_wait’:
serialport.c:1476:29: error: expected expression before ‘>’ token
if (timercmp(&now, &end, >)) {
^
serialport.c:1481:57: error: expected expression before ‘>’ token
if ((timeout_overflow = timercmp(&delta, &max_delta, >)))
^
make[1]: *** [Makefile:526: serialport.lo] Error 1
make: *** [Makefile:397: all] Error 2
``In C (and many other programming languages), you want to deal with the first error first. In this case, the serialport.c:785:2: error: unknown type name ‘fd_set’ fd_set fds;
error message. For some reason, on your system, the pre-processor doesn't know about fd_set. Perhaps you're missing some header files? Do you know what compiler specific packages you installed when you installed MSYS2?
You might want to try something like: pacman -Sy # this synchronizes the database with the latest repository pacman -S make gettext base-devel mingw-w64-x86_64-gcc
Or something along those lines.... base-devel contains a bunch of utilities and stuff that you might be missing. I'm not sure if you're compiling for 64-bit or 32-bit or both, but I'm certain you already have a compiler installed. I just added the mingw-w64-x86_64-gcc incase other people come across this thread. Let me know how you make out.
menesty
commented
7 years ago I am really new of compiling all this stuff related with c/c++ under windows, I have not problem under maos result of execution pacman -Sy :: Synchronizing package databases... mingw32 is up to date mingw64 is up to date msys is up to date
after run this command : pacman -S make gettext base-devel mingw-w64-x86_64-gcc all install but error do not disappeared . I have windows 7 64bit Can it be the problem like described on this topic ? https://github.com/curl/curl/issues/749
Spork-Schivago
commented
7 years ago I guess it wouldn't hurt to try manually selecting the header file, like in the curl issue you linked to. I really think it might just be a missing dependency though. When I start feeling better (I'm really sick), I'll try compiling under Windows and see if I can duplicate your problem. If it compiles, I'll post the steps I took. If I get the same error, I'll try finding out why and post how to fix it.
Thanks.
menesty
commented
7 years ago Thanks, take care
pt300
commented
6 years ago For future reference:
That problem is caused by the default gcc from msys2 not setting _WIN32 but __CYGWIN__ instead. One solution is to change ifdefs to check whether _WIN32 OR __CYGWIN__ is defined. Second solution is to install gcc from mingw* repository instead
martinling
commented
6 years ago I'm closing this since everyone seems to have gotten the help they needed and I can't see an underlying libserialport issue.
pt300
commented
6 years ago I stated that the problem with libserialport is that it checks only if _WIN32 is defined where it should check whether _WIN32 or __CYGWIN__ is defined. That's what causes problems for most people. I can create a patch if needed.
martinling
commented
6 years ago @pt300 that's a valid issue in #19 and already in the upstream tracker here: https://sigrok.org/bugzilla/show_bug.cgi?id=963
I'm leaving this issue #10 closed though as it's a long discussion about multiple unrelated matters.
I'm afraid I don't understand the instructions to use this library. Sorry, I'm a bit new. I've installed CodeBlocks (this one: "codeblocks-13.12mingw-setup.exe" here: http://www.codeblocks.org/downloads/26#windows) and MSYS2 64-bit (I downloaded & followed all instructions here: https://msys2.github.io/) but now I have no idea how to make the library usable in CodeBlocks.
What do I do next?