From: Jörg K. <joe...@em...> - 2016-03-26 20:54:36
|
This series of patches fix build issues with the musl C library [1]. musl is used as the default C library in OpenWRT and Alpine and is supported by other Linux distros (Gentoo, Arch, Debian) and other projects (Buildroot, Rust, ...). Short summary about the patches: 1) Replace some non-ANSI, legacy functions by their replacements 2) Remove __P() macro 3) Remove <sys/sysctl.h> 4) Check for GLOB_TILDE 5) Replace strtoq by strtoull 6) Include <signal.h> instead of <sys/signal.h> As the projects CVS repository on sourceforge is outdated, I created the patches from the sources with the version 0.8.2. Best regards Jörg Krause |
From: Jörg K. <joe...@em...> - 2016-04-22 09:16:56
|
This series of patches fix build issues with the musl C library [1]. musl is used as the default C library in OpenWRT and Alpine and is supported by other Linux distros (Gentoo, Arch, Debian) and other projects (Buildroot, Rust, ...). Short summary about the patches: 1) Remove __P() macro 2) Remove <sys/sysctl.h> 3) Check for GLOB_TILDE 4) Replace strtouq by strtoull 5) Include <signal.h> instead of <sys/signal.h> As the projects CVS repository on sourceforge is outdated, I created the patches from the sources with the version 0.8.2. Changes v1 -> v2: * Seperate non-SUSv3 fix from this patch set * Define GLOB_TILDE with 0 if not defined * Use autoconf to check for strtouq Best regards Jörg Krause |
From: Jörg K. <joe...@em...> - 2016-05-08 10:43:38
|
This series of patches fix build issues with the musl C library [1]. musl is used as the default C library in OpenWRT and Alpine and is supported by other Linux distros (Gentoo, Arch, Debian) and projects (Buildroot, Rust, ...). Short summary about the patches: 1) Fix missing definition of __P() macro 2) Remove unneeded <sys/sysctl.h> 3) Check for GLOB_TILDE 4) Check for strtouq 5) Fix redirection of <sys/signal.h> As the projects CVS repository on sourceforge is outdated, I created the patches from the sources with the version 0.8.2. [1] http://www.musl-libc.org Changes v2 -> v3: * do not get rid of __P, but include the compatibility header gnuc.h whenever needed (suggested by Rainer Weikusat) Changes v1 -> v2: * Seperate non-SUSv3 fix from this patch set * Define GLOB_TILDE with 0 if not defined (suggested by Rainer Weikusat) * Use autoconf to check for strtouq (suggested by Rainer Weikusat) Best regards Jörg Krause |
From: Reinoud K. <rei...@gm...> - 2016-05-09 05:34:25
|
On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em...cks> wrote: > This series of patches fix build issues with the musl C library [1]. > > musl is used as the default C library in OpenWRT and Alpine and is > supported by other Linux distros (Gentoo, Arch, Debian) and projects > (Buildroot, Rust, ...). > > Short summary about the patches: > 1) Fix missing definition of __P() macro > 2) Remove unneeded <sys/sysctl.h> > 3) Check for GLOB_TILDE > 4) Check for strtouq > 5) Fix redirection of <sys/signal.h> > > As the projects CVS repository on sourceforge is outdated, I created > the patches from the sources with the version 0.8.2. > > [1] http://www.musl-libc.org > > Changes v2 -> v3: > * do not get rid of __P, but include the compatibility header gnuc.h > whenever needed (suggested by Rainer Weikusat) Why keep the __P macro? it's ancient now and if musl can't deal with it, but compiles without it, then we should remove it if uclibc-ng, glibc and musl can compile all. You are suggesting to include gnuc.h in ipsec-tools? Also good with me, however, then we must maintain that file as well and keep it in check with newer versions. As of now I do not understand why we should keep __P, what does it bring us that we otherwise wouldn't have? > > > Changes v1 -> v2: > * Seperate non-SUSv3 fix from this patch set > * Define GLOB_TILDE with 0 if not defined (suggested by Rainer > Weikusat) > * Use autoconf to check for strtouq (suggested by Rainer Weikusat) > > Best regards > Jörg Krause > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: Jörg K. <joe...@em...> - 2016-05-09 07:19:07
|
On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: > On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em... > cks> wrote: > > This series of patches fix build issues with the musl C library > > [1]. > > > > musl is used as the default C library in OpenWRT and Alpine and is > > supported by other Linux distros (Gentoo, Arch, Debian) and > > projects > > (Buildroot, Rust, ...). > > > > Short summary about the patches: > > 1) Fix missing definition of __P() macro > > 2) Remove unneeded <sys/sysctl.h> > > 3) Check for GLOB_TILDE > > 4) Check for strtouq > > 5) Fix redirection of <sys/signal.h> > > > > As the projects CVS repository on sourceforge is outdated, I > > created > > the patches from the sources with the version 0.8.2. > > > > [1] http://www.musl-libc.org > > > > Changes v2 -> v3: > > * do not get rid of __P, but include the compatibility header > > gnuc.h > > whenever needed (suggested by Rainer Weikusat) > > Why keep the __P macro? it's ancient now and if musl can't deal with > it, but compiles without it, then we should remove it if uclibc-ng, > glibc and musl can compile all. You are suggesting to include gnuc.h > in ipsec-tools? > Also good with me, however, then we must maintain that file as well > and keep it in check with newer versions. > As of now I do not understand why we should keep __P, what does it > bring us that we otherwise wouldn't have? The only feedback I got for the patch was from Rainer Weikusat, who proposed to stay with __P and use the gnuc.h instead [1]. Note, that gnuc.h is already part of ipsec-tools. It's in the racoon subdirectory. I moved it, so it is available for the sources of the other subdirectories. I do not have a strong opinion if __P should be removed or not. Btw, who is maintaining this project? [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/ |
From: Reinoud K. <rei...@gm...> - 2016-05-09 08:29:03
|
On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...cks> wrote: > On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: >> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em... >> cks> wrote: >> > This series of patches fix build issues with the musl C library >> > [1]. >> > >> > musl is used as the default C library in OpenWRT and Alpine and is >> > supported by other Linux distros (Gentoo, Arch, Debian) and >> > projects >> > (Buildroot, Rust, ...). >> > >> > Short summary about the patches: >> > 1) Fix missing definition of __P() macro >> > 2) Remove unneeded <sys/sysctl.h> >> > 3) Check for GLOB_TILDE >> > 4) Check for strtouq >> > 5) Fix redirection of <sys/signal.h> >> > >> > As the projects CVS repository on sourceforge is outdated, I >> > created >> > the patches from the sources with the version 0.8.2. >> > >> > [1] http://www.musl-libc.org >> > >> > Changes v2 -> v3: >> > * do not get rid of __P, but include the compatibility header >> > gnuc.h >> > whenever needed (suggested by Rainer Weikusat) >> >> Why keep the __P macro? it's ancient now and if musl can't deal with >> it, but compiles without it, then we should remove it if uclibc-ng, >> glibc and musl can compile all. You are suggesting to include gnuc.h >> in ipsec-tools? >> Also good with me, however, then we must maintain that file as well >> and keep it in check with newer versions. >> As of now I do not understand why we should keep __P, what does it >> bring us that we otherwise wouldn't have? > > The only feedback I got for the patch was from Rainer Weikusat, who > proposed to stay with __P and use the gnuc.h instead [1]. > > Note, that gnuc.h is already part of ipsec-tools. It's in the racoon > subdirectory. I moved it, so it is available for the sources of the > other subdirectories. > > I do not have a strong opinion if __P should be removed or not. Well, .... I don't really think it's necessary to keep. However, NetBSD also has racoon and likely keeps __P. Maybe for that sake we should keep it, not sure. > > Btw, who is maintaining this project? > We all do in a way. I Proposed a patch for 0.8.3 I need to spilt that patch up in different ones. Secondly, Rainer said there is still a leak present, but had no time yet to patch it up and logically didn't want 0.8.3 with that leak present. When he will publish the patch, I'll make a list of patches and submit it. Timo Terras offered to review it and create 0.8.3 as he's the lead. Despite what lots of people may think, there is still a fairly large community using ipsec-tools. By all means, if anybody will see something missing from the list that i'll propose, feel free to comment. Thanks, Reinoud. > [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/ |
From: Jörg K. <joe...@em...> - 2016-05-09 08:51:46
|
On Mo, 2016-05-09 at 02:28 -0600, Reinoud Koornstra wrote: > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em... > cks> wrote: > > On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: > >> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joerg.krause@embedded > .ro > >> cks> wrote: > >> > This series of patches fix build issues with the musl C library > >> > [1]. > >> > > >> > musl is used as the default C library in OpenWRT and Alpine and > is > >> > supported by other Linux distros (Gentoo, Arch, Debian) and > >> > projects > >> > (Buildroot, Rust, ...). > >> > > >> > Short summary about the patches: > >> > 1) Fix missing definition of __P() macro > >> > 2) Remove unneeded <sys/sysctl.h> > >> > 3) Check for GLOB_TILDE > >> > 4) Check for strtouq > >> > 5) Fix redirection of <sys/signal.h> > >> > > >> > As the projects CVS repository on sourceforge is outdated, I > >> > created > >> > the patches from the sources with the version 0.8.2. > >> > > >> > [1] http://www.musl-libc.org > >> > > >> > Changes v2 -> v3: > >> > * do not get rid of __P, but include the compatibility header > >> > gnuc.h > >> > whenever needed (suggested by Rainer Weikusat) > >> > >> Why keep the __P macro? it's ancient now and if musl can't deal > with > >> it, but compiles without it, then we should remove it if uclibc- > ng, > >> glibc and musl can compile all. You are suggesting to include > gnuc.h > >> in ipsec-tools? > >> Also good with me, however, then we must maintain that file as > well > >> and keep it in check with newer versions. > >> As of now I do not understand why we should keep __P, what does it > >> bring us that we otherwise wouldn't have? > > > > The only feedback I got for the patch was from Rainer Weikusat, who > > proposed to stay with __P and use the gnuc.h instead [1]. > > > > Note, that gnuc.h is already part of ipsec-tools. It's in the > racoon > > subdirectory. I moved it, so it is available for the sources of the > > other subdirectories. > > > > I do not have a strong opinion if __P should be removed or not. > > Well, .... I don't really think it's necessary to keep. > However, NetBSD also has racoon and likely keeps __P. > Maybe for that sake we should keep it, not sure. > > > > > Btw, who is maintaining this project? > > > > We all do in a way. > I Proposed a patch for 0.8.3 > I need to spilt that patch up in different ones. > Secondly, Rainer said there is still a leak present, but had no time > yet to patch it up and logically didn't want 0.8.3 with that leak > present. > When he will publish the patch, I'll make a list of patches and > submit it. > Timo Terras offered to review it and create 0.8.3 as he's the lead. > Despite what lots of people may think, there is still a fairly large > community using ipsec-tools. That's good news! > By all means, if anybody will see something missing from the list > that > i'll propose, feel free to comment. Is there an up-to-date repository (preferable git)? This would ease patch creation. Best regards Jörg Krause |
From: Reinoud K. <rei...@gm...> - 2016-05-09 08:32:06
|
On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra <rei...@gm...> wrote: > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...cks> wrote: >> On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: >>> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em... >>> cks> wrote: >>> > This series of patches fix build issues with the musl C library >>> > [1]. >>> > >>> > musl is used as the default C library in OpenWRT and Alpine and is >>> > supported by other Linux distros (Gentoo, Arch, Debian) and >>> > projects >>> > (Buildroot, Rust, ...). >>> > >>> > Short summary about the patches: >>> > 1) Fix missing definition of __P() macro >>> > 2) Remove unneeded <sys/sysctl.h> >>> > 3) Check for GLOB_TILDE >>> > 4) Check for strtouq >>> > 5) Fix redirection of <sys/signal.h> >>> > >>> > As the projects CVS repository on sourceforge is outdated, I >>> > created >>> > the patches from the sources with the version 0.8.2. >>> > >>> > [1] http://www.musl-libc.org >>> > >>> > Changes v2 -> v3: >>> > * do not get rid of __P, but include the compatibility header >>> > gnuc.h >>> > whenever needed (suggested by Rainer Weikusat) >>> >>> Why keep the __P macro? it's ancient now and if musl can't deal with >>> it, but compiles without it, then we should remove it if uclibc-ng, >>> glibc and musl can compile all. You are suggesting to include gnuc.h >>> in ipsec-tools? >>> Also good with me, however, then we must maintain that file as well >>> and keep it in check with newer versions. >>> As of now I do not understand why we should keep __P, what does it >>> bring us that we otherwise wouldn't have? >> >> The only feedback I got for the patch was from Rainer Weikusat, who >> proposed to stay with __P and use the gnuc.h instead [1]. >> >> Note, that gnuc.h is already part of ipsec-tools. It's in the racoon >> subdirectory. I moved it, so it is available for the sources of the >> other subdirectories. >> >> I do not have a strong opinion if __P should be removed or not. > > Well, .... I don't really think it's necessary to keep. > However, NetBSD also has racoon and likely keeps __P. > Maybe for that sake we should keep it, not sure. > >> I really like your patches though and I think they should be included in 0.8.3. If Rainer is Ok with your patches I think I can safely include them in the proposal for 0.8.3. >> Btw, who is maintaining this project? >> > > We all do in a way. > I Proposed a patch for 0.8.3 > I need to spilt that patch up in different ones. > Secondly, Rainer said there is still a leak present, but had no time > yet to patch it up and logically didn't want 0.8.3 with that leak > present. > When he will publish the patch, I'll make a list of patches and submit it. > Timo Terras offered to review it and create 0.8.3 as he's the lead. > Despite what lots of people may think, there is still a fairly large > community using ipsec-tools. > By all means, if anybody will see something missing from the list that > i'll propose, feel free to comment. > Thanks, > > Reinoud. > >> [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/ |
From: Jörg K. <joe...@em...> - 2016-05-09 08:47:45
|
On Mo, 2016-05-09 at 02:32 -0600, Reinoud Koornstra wrote: > On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra > <rei...@gm...> wrote: > > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joerg.krause@embedded. > > rocks> wrote: > > > On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: > > > > On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joerg.krause@embed > > > > ded.ro > > > > cks> wrote: > > > > > This series of patches fix build issues with the musl C > > > > > library > > > > > [1]. > > > > > > > > > > musl is used as the default C library in OpenWRT and Alpine > > > > > and is > > > > > supported by other Linux distros (Gentoo, Arch, Debian) and > > > > > projects > > > > > (Buildroot, Rust, ...). > > > > > > > > > > Short summary about the patches: > > > > > 1) Fix missing definition of __P() macro > > > > > 2) Remove unneeded <sys/sysctl.h> > > > > > 3) Check for GLOB_TILDE > > > > > 4) Check for strtouq > > > > > 5) Fix redirection of <sys/signal.h> > > > > > > > > > > As the projects CVS repository on sourceforge is outdated, I > > > > > created > > > > > the patches from the sources with the version 0.8.2. > > > > > > > > > > [1] http://www.musl-libc.org > > > > > > > > > > Changes v2 -> v3: > > > > > * do not get rid of __P, but include the compatibility > > > > > header > > > > > gnuc.h > > > > > whenever needed (suggested by Rainer Weikusat) > > > > > > > > Why keep the __P macro? it's ancient now and if musl can't deal > > > > with > > > > it, but compiles without it, then we should remove it if > > > > uclibc-ng, > > > > glibc and musl can compile all. You are suggesting to include > > > > gnuc.h > > > > in ipsec-tools? > > > > Also good with me, however, then we must maintain that file as > > > > well > > > > and keep it in check with newer versions. > > > > As of now I do not understand why we should keep __P, what does > > > > it > > > > bring us that we otherwise wouldn't have? > > > > > > The only feedback I got for the patch was from Rainer Weikusat, > > > who > > > proposed to stay with __P and use the gnuc.h instead [1]. > > > > > > Note, that gnuc.h is already part of ipsec-tools. It's in the > > > racoon > > > subdirectory. I moved it, so it is available for the sources of > > > the > > > other subdirectories. > > > > > > I do not have a strong opinion if __P should be removed or not. > > > > Well, .... I don't really think it's necessary to keep. > > However, NetBSD also has racoon and likely keeps __P. > > Maybe for that sake we should keep it, not sure. > > > > > > > I really like your patches though and I think they should be included > in 0.8.3. > If Rainer is Ok with your patches I think I can safely include them > in > the proposal for 0.8.3. You're welcome! There might be an issue with simply replacing strtouq with strtoul or strtoull if strtouq is not available [1]. I guess autoconf should check for the size of unsigned long long and unsigned long, too. [1] http://lists.busybox.net/pipermail/buildroot/2016-May/160719.html |
From: Reinoud K. <rei...@gm...> - 2016-05-09 10:30:26
|
On Mon, May 9, 2016 at 2:47 AM, Jörg Krause <joe...@em...cks> wrote: > On Mo, 2016-05-09 at 02:32 -0600, Reinoud Koornstra wrote: >> On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra >> <rei...@gm...> wrote: >> > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joerg.krause@embedded. >> > rocks> wrote: >> > > On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: >> > > > On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joerg.krause@embed >> > > > ded.ro >> > > > cks> wrote: >> > > > > This series of patches fix build issues with the musl C >> > > > > library >> > > > > [1]. >> > > > > >> > > > > musl is used as the default C library in OpenWRT and Alpine >> > > > > and is >> > > > > supported by other Linux distros (Gentoo, Arch, Debian) and >> > > > > projects >> > > > > (Buildroot, Rust, ...). >> > > > > >> > > > > Short summary about the patches: >> > > > > 1) Fix missing definition of __P() macro >> > > > > 2) Remove unneeded <sys/sysctl.h> >> > > > > 3) Check for GLOB_TILDE >> > > > > 4) Check for strtouq >> > > > > 5) Fix redirection of <sys/signal.h> >> > > > > >> > > > > As the projects CVS repository on sourceforge is outdated, I >> > > > > created >> > > > > the patches from the sources with the version 0.8.2. >> > > > > >> > > > > [1] http://www.musl-libc.org >> > > > > >> > > > > Changes v2 -> v3: >> > > > > * do not get rid of __P, but include the compatibility >> > > > > header >> > > > > gnuc.h >> > > > > whenever needed (suggested by Rainer Weikusat) >> > > > >> > > > Why keep the __P macro? it's ancient now and if musl can't deal >> > > > with >> > > > it, but compiles without it, then we should remove it if >> > > > uclibc-ng, >> > > > glibc and musl can compile all. You are suggesting to include >> > > > gnuc.h >> > > > in ipsec-tools? >> > > > Also good with me, however, then we must maintain that file as >> > > > well >> > > > and keep it in check with newer versions. >> > > > As of now I do not understand why we should keep __P, what does >> > > > it >> > > > bring us that we otherwise wouldn't have? >> > > >> > > The only feedback I got for the patch was from Rainer Weikusat, >> > > who >> > > proposed to stay with __P and use the gnuc.h instead [1]. >> > > >> > > Note, that gnuc.h is already part of ipsec-tools. It's in the >> > > racoon >> > > subdirectory. I moved it, so it is available for the sources of >> > > the >> > > other subdirectories. >> > > >> > > I do not have a strong opinion if __P should be removed or not. >> > >> > Well, .... I don't really think it's necessary to keep. >> > However, NetBSD also has racoon and likely keeps __P. >> > Maybe for that sake we should keep it, not sure. >> > >> > > >> >> I really like your patches though and I think they should be included >> in 0.8.3. >> If Rainer is Ok with your patches I think I can safely include them >> in >> the proposal for 0.8.3. > > You're welcome! > > There might be an issue with simply replacing strtouq with strtoul or > strtoull if strtouq is not available [1]. I guess autoconf should check > for the size of unsigned long long and unsigned long, too. that would be good indeed. As resilient as possible. :) > > [1] http://lists.busybox.net/pipermail/buildroot/2016-May/160719.html |
From: Rainer W. <rwe...@mo...> - 2016-05-09 10:36:02
|
Reinoud Koornstra <rei...@gm...> writes: > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause > <joe...@em...cks> wro [...] >> I do not have a strong opinion if __P should be removed or not. > > Well, .... I don't really think it's necessary to keep. > However, NetBSD also has racoon and likely keeps __P. > Maybe for that sake we should keep it, not sure. Removing __P means a huge 'coding style' change which is difficult/ impossible to audit and doesn't add anything of value (at best). |
From: Jörg K. <joe...@em...> - 2016-05-10 18:53:47
|
On Mo, 2016-05-09 at 11:35 +0100, Rainer Weikusat wrote: > Reinoud Koornstra <rei...@gm...> writes: > > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause > > <joe...@em...cks> wro > > [...] > > > > I do not have a strong opinion if __P should be removed or not. > > > > Well, .... I don't really think it's necessary to keep. > > However, NetBSD also has racoon and likely keeps __P. > > Maybe for that sake we should keep it, not sure. > > Removing __P means a huge 'coding style' change which is difficult/ > impossible to audit and doesn't add anything of value (at best). Do you agree with the current patch for __P? Best regards Jörg Krause |
From: Anthony G. B. <ba...@op...> - 2016-05-09 10:39:04
|
On 5/9/16 4:32 AM, Reinoud Koornstra wrote: > On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra > <rei...@gm...> wrote: >> On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...cks> wrote: >>> On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: >>>> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em... >>>> cks> wrote: >>>>> This series of patches fix build issues with the musl C library >>>>> [1]. >>>>> >>>>> musl is used as the default C library in OpenWRT and Alpine and is >>>>> supported by other Linux distros (Gentoo, Arch, Debian) and >>>>> projects >>>>> (Buildroot, Rust, ...). >>>>> >>>>> Short summary about the patches: >>>>> 1) Fix missing definition of __P() macro >>>>> 2) Remove unneeded <sys/sysctl.h> >>>>> 3) Check for GLOB_TILDE >>>>> 4) Check for strtouq >>>>> 5) Fix redirection of <sys/signal.h> >>>>> >>>>> As the projects CVS repository on sourceforge is outdated, I >>>>> created >>>>> the patches from the sources with the version 0.8.2. >>>>> >>>>> [1] http://www.musl-libc.org >>>>> >>>>> Changes v2 -> v3: >>>>> * do not get rid of __P, but include the compatibility header >>>>> gnuc.h >>>>> whenever needed (suggested by Rainer Weikusat) >>>> >>>> Why keep the __P macro? it's ancient now and if musl can't deal with >>>> it, but compiles without it, then we should remove it if uclibc-ng, >>>> glibc and musl can compile all. You are suggesting to include gnuc.h >>>> in ipsec-tools? >>>> Also good with me, however, then we must maintain that file as well >>>> and keep it in check with newer versions. >>>> As of now I do not understand why we should keep __P, what does it >>>> bring us that we otherwise wouldn't have? >>> >>> The only feedback I got for the patch was from Rainer Weikusat, who >>> proposed to stay with __P and use the gnuc.h instead [1]. >>> >>> Note, that gnuc.h is already part of ipsec-tools. It's in the racoon >>> subdirectory. I moved it, so it is available for the sources of the >>> other subdirectories. >>> >>> I do not have a strong opinion if __P should be removed or not. >> >> Well, .... I don't really think it's necessary to keep. >> However, NetBSD also has racoon and likely keeps __P. >> Maybe for that sake we should keep it, not sure. >> >>> > > I really like your patches though and I think they should be included in 0.8.3. > If Rainer is Ok with your patches I think I can safely include them in > the proposal for 0.8.3. I'm doing gentoo+musl, so I'm very interested in these patches. Have they been tested and if so with what musl based system? > > >>> Btw, who is maintaining this project? >>> >> >> We all do in a way. >> I Proposed a patch for 0.8.3 >> I need to spilt that patch up in different ones. >> Secondly, Rainer said there is still a leak present, but had no time >> yet to patch it up and logically didn't want 0.8.3 with that leak >> present. >> When he will publish the patch, I'll make a list of patches and submit it. >> Timo Terras offered to review it and create 0.8.3 as he's the lead. >> Despite what lots of people may think, there is still a fairly large >> community using ipsec-tools. >> By all means, if anybody will see something missing from the list that >> i'll propose, feel free to comment. >> Thanks, >> >> Reinoud. >> >>> [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/ > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 |
From: Reinoud K. <rei...@gm...> - 2016-05-09 11:35:35
|
It doesn't matter too much what musl based system. ipsec-tools now compiles and runs on a system with musl as c library, that should include yours as well. Best thing to do is download his patches, apply them, compile and run. :) That's the best way, not too much effort to try I'd say. Please let us know your experience. Thanks, Reinoud. On Mon, May 9, 2016 at 4:19 AM, Anthony G. Basile <ba...@op...> wrote: > On 5/9/16 4:32 AM, Reinoud Koornstra wrote: >> On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra >> <rei...@gm...> wrote: >>> On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...cks> wrote: >>>> On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote: >>>>> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em... >>>>> cks> wrote: >>>>>> This series of patches fix build issues with the musl C library >>>>>> [1]. >>>>>> >>>>>> musl is used as the default C library in OpenWRT and Alpine and is >>>>>> supported by other Linux distros (Gentoo, Arch, Debian) and >>>>>> projects >>>>>> (Buildroot, Rust, ...). >>>>>> >>>>>> Short summary about the patches: >>>>>> 1) Fix missing definition of __P() macro >>>>>> 2) Remove unneeded <sys/sysctl.h> >>>>>> 3) Check for GLOB_TILDE >>>>>> 4) Check for strtouq >>>>>> 5) Fix redirection of <sys/signal.h> >>>>>> >>>>>> As the projects CVS repository on sourceforge is outdated, I >>>>>> created >>>>>> the patches from the sources with the version 0.8.2. >>>>>> >>>>>> [1] http://www.musl-libc.org >>>>>> >>>>>> Changes v2 -> v3: >>>>>> * do not get rid of __P, but include the compatibility header >>>>>> gnuc.h >>>>>> whenever needed (suggested by Rainer Weikusat) >>>>> >>>>> Why keep the __P macro? it's ancient now and if musl can't deal with >>>>> it, but compiles without it, then we should remove it if uclibc-ng, >>>>> glibc and musl can compile all. You are suggesting to include gnuc.h >>>>> in ipsec-tools? >>>>> Also good with me, however, then we must maintain that file as well >>>>> and keep it in check with newer versions. >>>>> As of now I do not understand why we should keep __P, what does it >>>>> bring us that we otherwise wouldn't have? >>>> >>>> The only feedback I got for the patch was from Rainer Weikusat, who >>>> proposed to stay with __P and use the gnuc.h instead [1]. >>>> >>>> Note, that gnuc.h is already part of ipsec-tools. It's in the racoon >>>> subdirectory. I moved it, so it is available for the sources of the >>>> other subdirectories. >>>> >>>> I do not have a strong opinion if __P should be removed or not. >>> >>> Well, .... I don't really think it's necessary to keep. >>> However, NetBSD also has racoon and likely keeps __P. >>> Maybe for that sake we should keep it, not sure. >>> >>>> >> >> I really like your patches though and I think they should be included in 0.8.3. >> If Rainer is Ok with your patches I think I can safely include them in >> the proposal for 0.8.3. > > I'm doing gentoo+musl, so I'm very interested in these patches. Have > they been tested and if so with what musl based system? > >> >> >>>> Btw, who is maintaining this project? >>>> >>> >>> We all do in a way. >>> I Proposed a patch for 0.8.3 >>> I need to spilt that patch up in different ones. >>> Secondly, Rainer said there is still a leak present, but had no time >>> yet to patch it up and logically didn't want 0.8.3 with that leak >>> present. >>> When he will publish the patch, I'll make a list of patches and submit it. >>> Timo Terras offered to review it and create 0.8.3 as he's the lead. >>> Despite what lots of people may think, there is still a fairly large >>> community using ipsec-tools. >>> By all means, if anybody will see something missing from the list that >>> i'll propose, feel free to comment. >>> Thanks, >>> >>> Reinoud. >>> >>>> [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/ >> >> ------------------------------------------------------------------------------ >> Find and fix application performance issues faster with Applications Manager >> Applications Manager provides deep performance insights into multiple tiers of >> your business applications. It resolves application problems quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> _______________________________________________ >> Ipsec-tools-devel mailing list >> Ips...@li... >> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel >> > > > -- > Anthony G. Basile, Ph. D. > Chair of Information Technology > D'Youville College > Buffalo, NY 14201 > (716) 829-8197 > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |