While adding the freebsd platform into the supported build environments
the check for the needed ctags binary was modified
(aa7256a812), unfortunately the changes
made aren't correct and due this the target check_ctags in the toplevel
makefile was always assuming the correct ctags binary is around.
This was resulting in broken libcoap-1.{map,sym} files if 'make dist'
was called in case the user hasn't installed exuberant-ctags like ctags.
This change excludes the coap subdirectory from the include path
reported by pkg-config --cflags to avoid name conflicts with other
installed packages. Applications now must add the prefix 'coap/'
to include directives for libcoap header files, e.g.
#include <coap/coap.h>
Jean-Claude Michelou has reported this problem in Bug #82 [1].
[1] https://github.com/obgm/libcoap/issues/82
A minimal Makefile now could look be written as:
PKG_LIBCOAP=libcoap-1
CPPFLAGS=$(shell pkg-config --cflags-only-I $(PKG_LIBCOAP)) -DWITH_POSIX
LDFLAGS=$(shell pkg-config --libs-only-L $(PKG_LIBCOAP))
LDLIBS=$(shell pkg-config --libs-only-l $(PKG_LIBCOAP))
We are going into a new release cycle which will provide new so we need
new symbols and interfaces. Because of the new added symbols we need to
increase LT_LIBCOAP_CURRENT to '1'.
And we will be backward compatible and existing binaries linked against
the previous version will also working with that new planned library
release. To show this setting tune LT_LIBCOAP_AGE also to '1' as we are
now one version backward compatible.
To do a more finely graduated versioning a extra new field for the
release-state is added. The purpose is mainly to add some extra
information about the development state of libcoap like a alpha state
right after a final release or marking the state as a release candidate
before a planned release.
Starting with a string 'alpha' as we are in a really early development
state for the upcoming release.
Do not make reference to NDEBUG in public headers to modify the ABI. This macro is defined automatically in all windows projects and will create a lot of confusion.
Prevent invalid addresses from being used as source address with sendmsg. On linux, they are just ignored, so it is the same as not specifying one, but on windows they cause an error. In both case it is simpler not to include any control info if the intent is to let the interface be chosen by the network stack.
Merge changes from PR #47 related to windows platform support.
Add full windows platform support including correct error checking and working regression tests and examples.
Remove need to build applications using libcoap with -DWITH_POSIX and to include coap_config.h. This applies to the examples as well.
This update enables cross-compilation by specifying the option
--host to configure. For example, building libcoap with tinydtls
for raspberry pi now can be done as follows (given that you have
the required compiler; on Debian, apt-get install gcc-arm-linux-gnueabihf
should do):
git submodule update --init --recursive
./autogen.sh
./configure --host=arm-linux-gnueabihf --disable-shared --disable-documentation
make
The error that happen while cross compiling is quite logical if you
know what the check AC_FUNC_MALLOC is made for. The behavior isn't
really wrong (for me) because autoconf can't really test the created
code due it's for another platform. Some nice explanation about the
whole problem can be found here:
http://wiki.buici.com/xwiki/bin/view/Programing+C+and+C%2B%2B/Autoconf+and+RPL_MALLOC
As long as libcoap uses malloc from the libc we need a check for
the proper implementation for this cases. So removing AC_FUNC_MALLOC
isn't solving the problem. We need at least a check for a malloc
functionality which can be done by AC_CHECK_FUNC(S).
(cherry picked from commit 04d806fe4d)
jcmichelou