All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kang Kai <Kai.Kang@windriver.com>
To: Joe MacDonald <Joe_MacDonald@mentor.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6
Date: Tue, 22 Sep 2015 15:49:36 +0800	[thread overview]
Message-ID: <56010810.2020207@windriver.com> (raw)
In-Reply-To: <20150921183945.GA4700@mentor.com>

On 2015年09月22日 02:39, Joe MacDonald wrote:
> Hi Kai,
>
> [[oe] [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6] On 15.09.18 (Fri 17:14) kai.kang@windriver.com wrote:
>
>> From: Kai Kang <kai.kang@windriver.com>
>>
>> Upgrade xl2tpd v1.3.0-46-gdf7e30e to 1.3.6.
>>
>> * drop PR
>> * add patch to fix build failure with gcc 5.x
>>
>> Signed-off-by: Kai Kang <kai.kang@windriver.com>
>> ---
>>   .../recipes-protocols/xl2tpd/xl2tpd.inc            |   2 -
>>   .../fix-inline-functions-errors-with-gcc-5.x.patch | 116 +++++++++++++++++++++
>>   .../recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb       |   5 +
>>   .../recipes-protocols/xl2tpd/xl2tpd_git.bb         |   5 -
>>   4 files changed, 121 insertions(+), 7 deletions(-)
>>   create mode 100644 meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
>>   create mode 100644 meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb
>>   delete mode 100644 meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb
>>
>> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
>> index 1a72fd1..03a1a0b 100644
>> --- a/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
>> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd.inc
>> @@ -6,8 +6,6 @@ DEPENDS = "ppp virtual/kernel"
>>   LICENSE = "GPLv2"
>>   LIC_FILES_CHKSUM = "file://LICENSE;md5=0636e73ff0215e8d672dc4c32c317bb3"
>>   
>> -INC_PR = "r0"
>> -
>>   SRC_URI = "git://github.com/xelerance/xl2tpd.git"
>>   
>>   S = "${WORKDIR}/git"
>> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
>> new file mode 100644
>> index 0000000..dc78f02
>> --- /dev/null
>> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd/fix-inline-functions-errors-with-gcc-5.x.patch
>> @@ -0,0 +1,116 @@
>> +Upstream-Status: Pending
>> +
>> +GCC 5.x defaults to -std=gnu11 instead of -std=gnu89. The semantics for
>> +inline functions changes which causes build failures such as:
>> +
>> +| misc.h:68:20: warning: inline function 'swaps' declared but never defined
>> +|  extern inline void swaps (void *, int);
>> +|                      ^
>> +
>> +and
>> +
>> +| control.c:1717: undefined reference to `check_control'
>> +
>> +Fix them by:
>> +1 drop 'inline' attribute for function swap()
> The question about whether 'inline' belongs in a .c file or not aside
> (that's obviously not your department, that's how it is in the original
> code), why is swaps() treated differently than every other function?  If
> the compiler really needed to be told 'inline' on all of these, this
> just ensures that swaps() is never inlined.  Is that your intent?

For the functions except swap(), they are not referred by other .c 
files. So they are not needed to be exported and can be mark as static 
inline.

For swap(), it is referred by other .c files. It must be exported.

But the semantics for inline functions changes from gcc 4.x to gcc 5.x. 
GCC 5 defaults to -std=gnu11 instead of -std=gnu89.
While|-std=gnu89|employs the GNU89 inline semantics,|-std=gnu11|uses the 
C99 inline semantics.

  * C99|inline|: No externally visible function is generated. If the
    function is referenced in this TU, an external definition has to
    exist in another TU; same as GNU89|extern inline|with no redefinition.
  * C99|extern inline|: An externally visible function is generated;
    same as GNU89|inline|.
  * GNU89|inline|: Same as C99|extern inline|.
  * GNU89|extern inline|: No externally visible function is generated;
    no equivalent in C99, because redefinition is not permitted.


There are not same meaning of  'extern inline'. For compatible with gcc 
4.x, I choose to remove the inline attribution from function swap().

Ref:
https://gcc.gnu.org/gcc-5/porting_to.html


Regards,
Kai

>
> -J.
>
>> +2 replace 'inline' with 'static inline' for other functions
>> +
>> +Signed-off-by: Kai Kang <kai.kang@windriver.com>
>> +---
>> + control.c | 8 ++++----
>> + misc.c    | 2 +-
>> + misc.h    | 2 +-
>> + network.c | 4 ++--
>> + 4 files changed, 8 insertions(+), 8 deletions(-)
>> +
>> +diff --git a/control.c b/control.c
>> +index 134a7bf..0ef505b 100644
>> +--- a/control.c
>> ++++ b/control.c
>> +@@ -1139,7 +1139,7 @@ int control_finish (struct tunnel *t, struct call *c)
>> +     return 0;
>> + }
>> +
>> +-inline int check_control (const struct buffer *buf, struct tunnel *t,
>> ++static inline int check_control (const struct buffer *buf, struct tunnel *t,
>> +                           struct call *c)
>> + {
>> +     /*
>> +@@ -1275,7 +1275,7 @@ inline int check_control (const struct buffer *buf, struct tunnel *t,
>> +     return 0;
>> + }
>> +
>> +-inline int check_payload (struct buffer *buf, struct tunnel *t,
>> ++static inline int check_payload (struct buffer *buf, struct tunnel *t,
>> +                           struct call *c)
>> + {
>> +     /*
>> +@@ -1381,7 +1381,7 @@ inline int check_payload (struct buffer *buf, struct tunnel *t,
>> + #endif
>> +     return 0;
>> + }
>> +-inline int expand_payload (struct buffer *buf, struct tunnel *t,
>> ++static inline int expand_payload (struct buffer *buf, struct tunnel *t,
>> +                            struct call *c)
>> + {
>> +     /*
>> +@@ -1561,7 +1561,7 @@ void send_zlb (void *data)
>> +     toss (buf);
>> + }
>> +
>> +-inline int write_packet (struct buffer *buf, struct tunnel *t, struct call *c,
>> ++static inline int write_packet (struct buffer *buf, struct tunnel *t, struct call *c,
>> +                          int convert)
>> + {
>> +     /*
>> +diff --git a/misc.c b/misc.c
>> +index 3092401..af90dbf 100644
>> +--- a/misc.c
>> ++++ b/misc.c
>> +@@ -170,7 +170,7 @@ void do_packet_dump (struct buffer *buf)
>> +     printf ("}\n");
>> + }
>> +
>> +-inline void swaps (void *buf_v, int len)
>> ++void swaps (void *buf_v, int len)
>> + {
>> + #ifdef __alpha
>> +     /* Reverse byte order alpha is little endian so lest save a step.
>> +diff --git a/misc.h b/misc.h
>> +index aafdc62..caab7a1 100644
>> +--- a/misc.h
>> ++++ b/misc.h
>> +@@ -65,7 +65,7 @@ extern void l2tp_log (int level, const char *fmt, ...);
>> + extern struct buffer *new_buf (int);
>> + extern void udppush_handler (int);
>> + extern int addfcs (struct buffer *buf);
>> +-extern inline void swaps (void *, int);
>> ++extern void swaps (void *, int);
>> + extern void do_packet_dump (struct buffer *);
>> + extern void status (const char *fmt, ...);
>> + extern void status_handler (int signal);
>> +diff --git a/network.c b/network.c
>> +index 5e5b8b2..b019c2c 100644
>> +--- a/network.c
>> ++++ b/network.c
>> +@@ -135,7 +135,7 @@ int init_network (void)
>> +     return 0;
>> + }
>> +
>> +-inline void extract (void *buf, int *tunnel, int *call)
>> ++static inline void extract (void *buf, int *tunnel, int *call)
>> + {
>> +     /*
>> +      * Extract the tunnel and call #'s, and fix the order of the
>> +@@ -155,7 +155,7 @@ inline void extract (void *buf, int *tunnel, int *call)
>> +     }
>> + }
>> +
>> +-inline void fix_hdr (void *buf)
>> ++static inline void fix_hdr (void *buf)
>> + {
>> +     /*
>> +      * Fix the byte order of the header
>> +--
>> +1.9.1
>> +
>> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb b/meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb
>> new file mode 100644
>> index 0000000..aac11b7
>> --- /dev/null
>> +++ b/meta-networking/recipes-protocols/xl2tpd/xl2tpd_1.3.6.bb
>> @@ -0,0 +1,5 @@
>> +require xl2tpd.inc
>> +
>> +SRCREV = "5619e1771048e74b729804e8602f409af0f3faea"
>> +
>> +SRC_URI += "file://fix-inline-functions-errors-with-gcc-5.x.patch"
>> diff --git a/meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb b/meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb
>> deleted file mode 100644
>> index bd084aa..0000000
>> --- a/meta-networking/recipes-protocols/xl2tpd/xl2tpd_git.bb
>> +++ /dev/null
>> @@ -1,5 +0,0 @@
>> -require xl2tpd.inc
>> -PR = "${INC_PR}.0"
>> -
>> -SRCREV = "df7e30eb199fc5710faa83866381aea18b66e60c"
>> -
>> -- 
>> 1.9.1
>>


-- 
Regards,
Neil | Kai Kang



  reply	other threads:[~2015-09-22  7:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-18  9:14 [meta-networking][PATCH] xl2tpd: 1.3.0 -> 1.3.6 kai.kang
2015-09-21 18:39 ` Joe MacDonald
2015-09-22  7:49   ` Kang Kai [this message]
2015-09-22 13:42     ` Joe MacDonald
  -- strict thread matches above, loose matches on Subject: below --
2015-11-30  7:38 kai.kang
2015-12-01  2:00 ` Joe MacDonald
2015-12-01  2:19   ` Kang Kai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56010810.2020207@windriver.com \
    --to=kai.kang@windriver.com \
    --cc=Joe_MacDonald@mentor.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.