[Libstoragemgmt-devel] [PATCH 7/9] daemon: Remove obsolete build comments

Discussion:

Christophe Fergeau

2014-10-17 11:12:06 UTC

The compilation instructions are no longer needed as the rest daemon
build is integrated in the main autotools-based build system.
---
daemon/lsm_rest.c | 5 -----
1 file changed, 5 deletions(-)

diff --git a/daemon/lsm_rest.c b/daemon/lsm_rest.c
index 51c5335..865d498 100644
--- a/daemon/lsm_rest.c
+++ b/daemon/lsm_rest.c
@@ -58,11 +58,6 @@ static json_bool json_object_object_get_ex(struct json_object* obj,
TODO: MHD_get_connection_values() with MHD_GET_ARGUMENT_KIND to
get all query argument
TODO: Check malloc() return code
-
- gcc lsm_rest.c -o lsm_restd \
- `pkg-config --cflags --libs libmicrohttpd xml2` \
- `xml2-config --libs` `xml2-config --cflags` \
- `pkd-config --cflags --libs json`
*/

void para_list_init(ParaList_t *para_list)

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:03 UTC

Permalink

c_binding/Makefile.am references some files from the util/ subdirectory.
This causes warning with newer automakes unless 'subdir-objects' is
used:

c_binding/Makefile.am:12: warning: source file 'util/qparams.c' is in a subdirectory,
c_binding/Makefile.am:12: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index c4692e0..a96cedb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([m4])
dnl Make automake keep quiet about wildcards & other GNUmake-isms
-AM_INIT_AUTOMAKE([-Wno-portability])
+AM_INIT_AUTOMAKE([-Wno-portability subdir-objects])
AM_MAINTAINER_MODE([enable])
# Enable silent build when available (Automake 1.11)
m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:01 UTC

Permalink

Currently, CPPFLAGS are set globally for both lsmd and lsm_restd through
the use of AM_CPPFLAGS. However, lsmd does not need any such flags, they
are only needed by lsm_restd. This commit moves the global AM_CPPFLAGS
to lsm_restd_CFLAGS. It also removes LIBGLIB_CFLAGS as glib is not used
here.
---
daemon/Makefile.am | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index 2855a49..521055f 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -1,7 +1,3 @@
-AM_CPPFLAGS = \
- $(LIBXML_CFLAGS) $(LIBGLIB_CFLAGS) \
- $(JSON_CFLAGS) $(LIBMICROHTTPD_CFLAGS)
-
bin_PROGRAMS = lsmd

EXTRA_DIST=lsm_rest.c lsm_rest.h
@@ -14,6 +10,6 @@ lsmd_SOURCES = lsm_daemon.c
if WITH_REST_API
bin_PROGRAMS += lsm_restd
lsm_restd_LDFLAGS=$(LIBMICROHTTPD_LIBS) $(JSON_LIBS) $(LIBXML_LIBS)
-lsm_restd_CFLAGS=-fPIE -DPIE
+lsm_restd_CFLAGS=-fPIE -DPIE $(LIBMICROHTTPD_CFLAGS) $(JSON_CFLAGS) $(LIBXML_CFLAGS)
lsm_restd_SOURCES= lsm_rest.c
endif

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:02 UTC

Permalink

DEPS is not the name of an automake variable (closest name would be
DEPENDENCIES, see
https://www.gnu.org/software/automake/manual/html_node/Variable-Index.html#Variable-Index
). Moreover nothing uses DEPS in the Makefile.am or in other build
system files so it can be removed.
---
c_binding/Makefile.am | 2 --
1 file changed, 2 deletions(-)

diff --git a/c_binding/Makefile.am b/c_binding/Makefile.am
index 54a2d58..e4b8e1b 100644
--- a/c_binding/Makefile.am
+++ b/c_binding/Makefile.am
@@ -13,5 +13,3 @@ libstoragemgmt_la_SOURCES= \
lsm_mgmt.cpp lsm_datatypes.hpp lsm_datatypes.cpp lsm_convert.hpp \
lsm_convert.cpp lsm_ipc.hpp lsm_ipc.cpp lsm_plugin_ipc.hpp \
lsm_plugin_ipc.cpp util/qparams.c util/qparams.h
-
-DEPS = $(top_builddir)/c_binding/libstoragemgmt.la

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:04 UTC

Permalink

"fils system" -> "file system"
---
c_binding/include/libstoragemgmt/libstoragemgmt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c_binding/include/libstoragemgmt/libstoragemgmt.h b/c_binding/include/libstoragemgmt/libstoragemgmt.h
index 85b8e4e..b421424 100644
--- a/c_binding/include/libstoragemgmt/libstoragemgmt.h
+++ b/c_binding/include/libstoragemgmt/libstoragemgmt.h
@@ -595,7 +595,7 @@ extern "C" {
uint32_t *fs_count, lsm_flag flags);

/**
- * Creates a new fils system from the specified pool
+ * Creates a new file system from the specified pool
* @param[in] conn Valid connection
* @param[in] pool Valid pool
* @param[in] name File system name

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:07 UTC

Permalink

The MHD_PLATFORM_H #define needs to be set before including
microhttpd.h, so it had no effect where it was placed.
This #define is useful when building on systems where the standard
headers defining uint64_t, size_t, ... are not available.
As we are building on reasonably standard platforms, we can rely let
microhttpd.h use the standard headers.
---
daemon/lsm_rest.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/daemon/lsm_rest.c b/daemon/lsm_rest.c
index 865d498..3cc44c8 100644
--- a/daemon/lsm_rest.c
+++ b/daemon/lsm_rest.c
@@ -51,10 +51,7 @@ static json_bool json_object_object_get_ex(struct json_object* obj,
}
#endif

-
-#define MHD_PLATFORM_H
-/* prevent 'microhttpd.h' to include other platform headers
-
+/*
TODO: MHD_get_connection_values() with MHD_GET_ARGUMENT_KIND to
get all query argument
TODO: Check malloc() return code

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:00 UTC

Permalink

The daemon does not need libstoragemgmt, so we don't need to reference
libstoragemgmt.la or its CFLAGS in daemon/Makefile.am
---
daemon/Makefile.am | 5 -----
1 file changed, 5 deletions(-)

diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index de45612..2855a49 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -1,14 +1,9 @@
AM_CPPFLAGS = \
- -I$(top_srcdir)/c_binding/include \
- -I$(top_builddir)/c_binding/include \
- -***@srcdir@/c_binding/include \
$(LIBXML_CFLAGS) $(LIBGLIB_CFLAGS) \
$(JSON_CFLAGS) $(LIBMICROHTTPD_CFLAGS)

bin_PROGRAMS = lsmd

-DEPS = $(top_builddir)/c_binding/libstoragemgmt.la
-
EXTRA_DIST=lsm_rest.c lsm_rest.h

lsmd_LDFLAGS=-Wl,-z,relro,-z,now -pie

--
2.1.0

Christophe Fergeau

2014-10-17 11:12:05 UTC

Permalink

This causes a warning on fedora 21 as this has been deprecated.
This commit switches to the recommended json_object_object_get_ex
replacement.
It also adds a fallback implementation of json_object_object_get_ex
using json_object_object_get as the new function is not available on
all systems we want to build on (eg EL6).
---
I don't know how far back we want to go with json/json-c support.
json_object_object_get_ex was introduced in json-c 0.10, but we require
either json >= 0.10 or any version of json-c.
I haven't done runtime tests of this code (fallback code and non-fallback code) as
I don't know at all how to get to the codepath triggering a call to the deprecated methods.

Christophe

configure.ac | 7 +++++++
daemon/lsm_rest.c | 27 ++++++++++++++++++++++++---
2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index a96cedb..c9c0b81 100644
--- a/configure.ac
+++ b/configure.ac
@@ -177,6 +177,13 @@ if test "x$with_rest_api" = "xyes"; then
PKG_CHECK_MODULES([JSON], [json-c], [], [
AC_MSG_ERROR([json-c development libraries 0.10 or later required])
])
+ old_CFLAGS=$CFLAGS
+ old_LIBS=$LIBS
+ CFLAGS="$CFLAGS $JSON_CFLAGS"
+ LIBS="$LIBS $JSON_LIBS"
+ AC_CHECK_FUNCS([json_object_object_get_ex])
+ CFLAGS="$old_CFLAGS"
+ LIBS="$old_LIBS"
])
fi
AM_CONDITIONAL([WITH_REST_API], [test "x$with_rest_api" = "xyes"])
diff --git a/daemon/lsm_rest.c b/daemon/lsm_rest.c
index 1f38235..51c5335 100644
--- a/daemon/lsm_rest.c
+++ b/daemon/lsm_rest.c
@@ -18,6 +18,9 @@
* Author: Gris Ge <***@redhat.com>
*/

+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/select.h>
@@ -35,6 +38,20 @@

#include "lsm_rest.h"

+#ifndef HAVE_JSON_OBJECT_OBJECT_GET_EX
+static json_bool json_object_object_get_ex(struct json_object* obj,
+ const char *key,
+ struct json_object **value)
+{
+ json_object *result;
+ result = json_object_object_get(obj, key);
+ *value = result;
+
+ return (result != NULL);
+}
+#endif
+
+
#define MHD_PLATFORM_H
/* prevent 'microhttpd.h' to include other platform headers

@@ -309,9 +326,13 @@ const char *rpc(int socket_fd, const char *method, ParaList_t *para_list,
return NULL;
}
json_object *recv_json = json_tokener_parse(recv_json_string);
- const char *result_str = json_object_to_json_string_ext(
- json_object_object_get(recv_json, "result"),
- JSON_C_TO_STRING_PRETTY);
+ json_object *result_json;
+ if (!json_object_object_get_ex(recv_json, "result", &result_json)){
+ printf("No 'result' node in received JSON data");
+ return NULL;
+ }
+ const char *result_str = json_object_to_json_string_ext(result_json,
+ JSON_C_TO_STRING_PRETTY);
return result_str;
}

--
2.1.0

Tony Asleson

2014-10-17 16:02:40 UTC

Permalink

Hi Christophe,

Thanks for your patch set.

When trying to build on EL6 I'm getting:

lsm_rest.c:42: error: static declaration of ‘json_object_object_get_ex’
follows non-static declaration
/usr/include/json/json_object.h:230: note: previous declaration of
‘json_object_object_get_ex’ was here

Error seems to stem from HAVE_JSON_OBJECT_OBJECT_GET_EX not being
defined, which would seem to indicate that something is not working with
AC_CHECK_FUNCS([json_object_object_get_ex]).

Please take a peek.

Thanks,
Tony

Post by Christophe Fergeau
This causes a warning on fedora 21 as this has been deprecated.
This commit switches to the recommended json_object_object_get_ex
replacement.
It also adds a fallback implementation of json_object_object_get_ex
using json_object_object_get as the new function is not available on
all systems we want to build on (eg EL6).
---
I don't know how far back we want to go with json/json-c support.
json_object_object_get_ex was introduced in json-c 0.10, but we require
either json >= 0.10 or any version of json-c.
I haven't done runtime tests of this code (fallback code and non-fallback code) as
I don't know at all how to get to the codepath triggering a call to the deprecated methods.
Christophe
configure.ac | 7 +++++++
daemon/lsm_rest.c | 27 ++++++++++++++++++++++++---
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index a96cedb..c9c0b81 100644
--- a/configure.ac
+++ b/configure.ac
@@ -177,6 +177,13 @@ if test "x$with_rest_api" = "xyes"; then
PKG_CHECK_MODULES([JSON], [json-c], [], [
AC_MSG_ERROR([json-c development libraries 0.10 or later required])
])
+ old_CFLAGS=$CFLAGS
+ old_LIBS=$LIBS
+ CFLAGS="$CFLAGS $JSON_CFLAGS"
+ LIBS="$LIBS $JSON_LIBS"
+ AC_CHECK_FUNCS([json_object_object_get_ex])
+ CFLAGS="$old_CFLAGS"
+ LIBS="$old_LIBS"
])
fi
AM_CONDITIONAL([WITH_REST_API], [test "x$with_rest_api" = "xyes"])
diff --git a/daemon/lsm_rest.c b/daemon/lsm_rest.c
index 1f38235..51c5335 100644
--- a/daemon/lsm_rest.c
+++ b/daemon/lsm_rest.c
@@ -18,6 +18,9 @@
*/
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/select.h>
@@ -35,6 +38,20 @@
#include "lsm_rest.h"
+#ifndef HAVE_JSON_OBJECT_OBJECT_GET_EX
+static json_bool json_object_object_get_ex(struct json_object* obj,
+ const char *key,
+ struct json_object **value)
+{
+ json_object *result;
+ result = json_object_object_get(obj, key);
+ *value = result;
+
+ return (result != NULL);
+}
+#endif
+
+
#define MHD_PLATFORM_H
/* prevent 'microhttpd.h' to include other platform headers
@@ -309,9 +326,13 @@ const char *rpc(int socket_fd, const char *method, ParaList_t *para_list,
return NULL;
}
json_object *recv_json = json_tokener_parse(recv_json_string);
- const char *result_str = json_object_to_json_string_ext(
- json_object_object_get(recv_json, "result"),
- JSON_C_TO_STRING_PRETTY);
+ json_object *result_json;
+ if (!json_object_object_get_ex(recv_json, "result", &result_json)){
+ printf("No 'result' node in received JSON data");
+ return NULL;
+ }
+ const char *result_str = json_object_to_json_string_ext(result_json,
+ JSON_C_TO_STRING_PRETTY);
return result_str;
}

Tony Asleson

2014-10-17 19:11:50 UTC

Permalink

Post by Tony Asleson
Error seems to stem from HAVE_JSON_OBJECT_OBJECT_GET_EX not being
defined, which would seem to indicate that something is not working with
AC_CHECK_FUNCS([json_object_object_get_ex]).

OK I took a longer look at this and the problem stems from the fact that
the first PKG_CHECK_MODULES evaluates to true on EL6 and fedora, thus we
don't evaluate anything in 'action-if-not-found' path which includes the
newly added:

AC_CHECK_FUNCS([json_object_object_get_ex])

So this check is totally missed and the code compile fails for it.

Changing to something like:

PKG_CHECK_MODULES([JSON], [json >= 0.10], [
old_CFLAGS=$CFLAGS
old_LIBS=$LIBS
CFLAGS="$CFLAGS $JSON_CFLAGS"
LIBS="$LIBS $JSON_LIBS"
AC_CHECK_FUNCS([json_object_object_get_ex])
CFLAGS="$old_CFLAGS"
LIBS="$old_LIBS"
], [
PKG_CHECK_MODULES([JSON], [json-c], [
old_CFLAGS=$CFLAGS
old_LIBS=$LIBS
CFLAGS="$CFLAGS $JSON_CFLAGS"
LIBS="$LIBS $JSON_LIBS"
AC_CHECK_FUNCS([json_object_object_get_ex])
CFLAGS="$old_CFLAGS"
LIBS="$old_LIBS"], [
AC_MSG_ERROR([json-c development libraries 0.10 or later required])
])
])

would work, but I'm wondering:

1. What specific reason Gris added:
PKG_CHECK_MODULES([JSON], [json-c]
2. There must be a simpler way to work this

Thanks,
Tony

Christophe Fergeau

2014-10-17 21:43:12 UTC

Permalink

Hey,

Post by Tony Asleson

OK I took a longer look at this and the problem stems from the fact that
the first PKG_CHECK_MODULES evaluates to true on EL6 and fedora, thus we
don't evaluate anything in 'action-if-not-found' path which includes the
AC_CHECK_FUNCS([json_object_object_get_ex])
So this check is totally missed and the code compile fails for it.
PKG_CHECK_MODULES([JSON], [json >= 0.10], [
old_CFLAGS=$CFLAGS
old_LIBS=$LIBS
CFLAGS="$CFLAGS $JSON_CFLAGS"
LIBS="$LIBS $JSON_LIBS"
AC_CHECK_FUNCS([json_object_object_get_ex])
CFLAGS="$old_CFLAGS"
LIBS="$old_LIBS"
], [
PKG_CHECK_MODULES([JSON], [json-c], [
old_CFLAGS=$CFLAGS
old_LIBS=$LIBS
CFLAGS="$CFLAGS $JSON_CFLAGS"
LIBS="$LIBS $JSON_LIBS"
AC_CHECK_FUNCS([json_object_object_get_ex])
CFLAGS="$old_CFLAGS"
LIBS="$old_LIBS"], [
AC_MSG_ERROR([json-c development libraries 0.10 or later required])
])
])

The bug is that I put the check inside the 'success' part of the
PKG_CHECK_MODULES checks while I meant to put it after these checks.
Changing the first hunk to this:

diff --git a/configure.ac b/configure.ac
index a96cedb..d84b6e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -178,6 +178,13 @@ if test "x$with_rest_api" = "xyes"; then
AC_MSG_ERROR([json-c development libraries 0.10 or later required])
])
])
+ old_CFLAGS=$CFLAGS
+ old_LIBS=$LIBS
+ CFLAGS="$CFLAGS $JSON_CFLAGS"
+ LIBS="$LIBS $JSON_LIBS"
+ AC_CHECK_FUNCS([json_object_object_get_ex])
+ CFLAGS="$old_CFLAGS"
+ LIBS="$old_LIBS"
fi
AM_CONDITIONAL([WITH_REST_API], [test "x$with_rest_api" = "xyes"])

works on RHEL6.

However, what is the oldest distro/json-c we want to support? EL6 has json-c
0.11 which already has the new function, so I'm not sure it's really worth
adding some fallback code for distros older than EL6. In which case, we only
need to raise the requirements to 0.11 in configure.ac, and the fallback
code can be dropped from the C file.
Let me know what is your preference (I'd go for #2/no fallback code) and I'll
send an updated patch.

Christophe

Tony Asleson

2014-10-17 21:55:34 UTC

Permalink

Post by Christophe Fergeau
However, what is the oldest distro/json-c we want to support? EL6 has json-c
0.11 which already has the new function, so I'm not sure it's really worth
adding some fallback code for distros older than EL6. In which case, we only
need to raise the requirements to 0.11 in configure.ac, and the fallback
code can be dropped from the C file.
Let me know what is your preference (I'd go for #2/no fallback code) and I'll
send an updated patch.

EL6 or later was my goal. My preference would be #2 too, unless Gris
has a compelling reason why we need to keep 0.10 supported.

Thanks,
Tony

Tony Asleson

2014-10-17 23:47:26 UTC

Permalink

Post by Tony Asleson

EL6 or later was my goal. My preference would be #2 too, unless Gris
has a compelling reason why we need to keep 0.10 supported.

EL6.5 on my laptop only has 0.10 (EPEL) and it contains the functions:

json_object_object_get
json_object_object_get_ex

As does the upstream git repo 0.10 branch.

EL5 appears to have the same version as EL6 in EPEL.

Christophe Fergeau

2014-10-18 10:15:02 UTC

Permalink

Hey,

Post by Christophe Fergeau

Post by Tony Asleson

EL6 or later was my goal. My preference would be #2 too, unless Gris
has a compelling reason why we need to keep 0.10 supported.

json_object_object_get
json_object_object_get_ex
As does the upstream git repo 0.10 branch.

Tony Asleson

2014-10-29 21:37:19 UTC

Permalink

Yes, I realized after sending my email that it was introduced in the
main EL6 package repository in 6.6.

Configure fails on el6.6 due to missing json-c.

After checking around it appears that the new json-c-devel 0.11 package
places the json.pc & json-c.pc files in /lib64/pkgconfig. All other
development packages appear to place them in /usr/lib64/pkgconfig,
including 0.10 EPEL package.

I believe this change is related to
https://bugzilla.redhat.com/show_bug.cgi?id=1134001

Regards,
Tony

------------------------------------------------------------------------------

Tony Asleson

2014-10-29 21:42:12 UTC

Permalink

Post by Tony Asleson

Yes, I realized after sending my email that it was introduced in the
main EL6 package repository in 6.6.

Configure fails on el6.6 due to missing json-c.
After checking around it appears that the new json-c-devel 0.11 package
places the json.pc & json-c.pc files in /lib64/pkgconfig. All other
development packages appear to place them in /usr/lib64/pkgconfig,
including 0.10 EPEL package.
I believe this change is related to
https://bugzilla.redhat.com/show_bug.cgi?id=1134001

Confirmed, bug already exists:
https://bugzilla.redhat.com/show_bug.cgi?id=1152088

-Tony

------------------------------------------------------------------------------

Christophe Fergeau

2014-10-29 22:02:12 UTC

Permalink

Post by Tony Asleson

Yes, I realized after sending my email that it was introduced in the
main EL6 package repository in 6.6.

Vaguely rings a bell, I think I set PKG_CONFIG_PATH manually to work
around that, and assumed this was a known issue, and how it's supposed
to be done. In retrospect, I should have mentioned this ;)

Christophe

Christophe Fergeau

2014-10-17 21:50:12 UTC

Permalink

Post by Christophe Fergeau
PKG_CHECK_MODULES([JSON], [json-c]

I guess this all boils down to
https://github.com/json-c/json-c/commit/30dd367c0a2467dc292f653ea3afd6ad4c6e034b

Initially, this library installed a json.pc file, but this was renamed
to json-c.pc between the 0.10 and 0.11 releases. If you want to support
0.10 or newer, you need to check for json.pc >= 0.10, or json-c.pc.
EL5 has the 0.10 version.

Christophe

Christophe Fergeau

2014-10-17 11:12:08 UTC

Permalink

---
daemon/lsm_rest.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/daemon/lsm_rest.c b/daemon/lsm_rest.c
index 3cc44c8..ec42cd7 100644
--- a/daemon/lsm_rest.c
+++ b/daemon/lsm_rest.c
@@ -146,7 +146,7 @@ json_object *para_list_to_json(ParaList_t *para_list)
return jobj;
}

-int connect_socket(const char *uri_str, const char *plugin_dir,
+static int connect_socket(const char *uri_str, const char *plugin_dir,
int *error_no)
{
int socket_fd = -1;
@@ -194,7 +194,7 @@ int connect_socket(const char *uri_str, const char *plugin_dir,
}

-int send_msg(int socket_fd, const char *msg, int *error_no)
+static int send_msg(int socket_fd, const char *msg, int *error_no)
{
int rc = -1;
size_t len = strlen(msg);
@@ -328,7 +328,7 @@ const char *rpc(int socket_fd, const char *method, ParaList_t *para_list,
return result_str;
}

-int plugin_startup(int socket_fd, const char *uri, const char *pass, int tmo)
+static int plugin_startup(int socket_fd, const char *uri, const char *pass, int tmo)
{
printf("Starting the plugin\n");
int error_no = 0;
@@ -345,7 +345,7 @@ int plugin_startup(int socket_fd, const char *uri, const char *pass, int tmo)
return error_no;
}

-int plugin_shutdown(int socket_fd)
+static int plugin_shutdown(int socket_fd)
{
printf("Shutting down the plugin\n");
int error_no = 0;
@@ -425,7 +425,7 @@ const char *lsm_api_0_1(struct MHD_Connection *connection,
return json_msg;
}

-int answer_to_connection(void *cls, struct MHD_Connection *connection,
+static int answer_to_connection(void *cls, struct MHD_Connection *connection,
const char *url,
const char *method, const char *version,
const char *upload_data,

--
2.1.0