From phk at phk.freebsd.dk Wed Jan 9 10:36:14 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Jan 2019 10:36:14 +0000 Subject: vtest status In-Reply-To: <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> Message-ID: <13120.1547030174@critter.freebsd.dk> -------- In message <58d74416-8e0f-4a35-bb7c-67f02a680fdc at haproxy.com>, Frederic Lecaille writes: >I hope everything is going well on your side. Well, getting better: One of my close friends died from stomach-cancer right before X-mas and that threw all plans askew. >So, if you need some help to make vtest project progress, please >do not hesitate to ask. I think what we need most right now, is to decide what shape vtest should take? I want to stress that I want this to be a collective decision, so don't take anything I write here as edict or diktat. Personally I am not very keen on turning vtest a "real" project with releases, package-building and all that, because it would cause me a lot of work which I don't think brings enough advantages. The problem for me is that vtc_varnish has a very incestuos relationship with varnish internals, internals which we do not want to turn into documented or even open APIs, and that means that vtc_varnish and varnishd must match versions. A stand-alone vtest-package would either need to be compiled against a specific version of varnish, or have some way to dynamically load vtc_varnish from from the varnish source/package it is being used against. But that just moves the problem to the other side of the line, where we need to open the internals of vtest up as a documented and versioned API... Some day (H3?) all that work may make sense, but I don't feel we are there yet, at least not as far as cost/benefit is concerned. My suggestion for now, is to let vtest live as a "source code library" on github and not build and distribute it as stand-alone packages. Instead it will be up to the projects which use it to import and build in their own projects. That way HAproxy and leave vtc_varnish out of their compilation so varnish does not become a build-dependency (or you can conditionally compile vtc_varnish in, if it is already there.) And we can compile it in Varnish including vtc_varnish, and include vtc_haproxy in similar fashion. (actually, compilation of vtc_haproxy does not need haproxy to be installed, does it ?) We should still provide a Makefile in the vtest github project which compiles as much as possible (ie: vtc_varnish if it can find varnish installed), that will make work on the shared sources easier for all of us. If we decide to do things that way, maybe you should call your compiled version something like "hatest", while we stick with "varnishtest", so we can reserve the "vtest" name for the future runtime-extensible all-singing-and-dancing thing ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Wed Jan 9 21:49:23 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Jan 2019 21:49:23 +0000 Subject: vtest status In-Reply-To: <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> Message-ID: <28833.1547070563@critter.freebsd.dk> -------- In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: >> My suggestion for now, is to let vtest live as a "source code >> library" on github and not build and distribute it as stand-alone >> packages. > >Currently, vtest convert.sh script make copies of lib/libvarnish/*.c >which are already compiled when compiling varnish sources providing >lib/libvarnish.a library. The convert.sh script is really only meant to show me what the difference is between the copy of vtest in the varnish cache project and in the vtest project. >Could not this vtest library be compiled against lib/libvarnish.a >library? The problem is that if you install a varnish package you do not have libvarnish.a, it is an internal static library. >As far as we do not have to make copies of file from varnish sources >to compile vtest this would help to its maintenance. Precisely. Watch out for a couple of commits... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Wed Jan 9 22:09:15 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Jan 2019 22:09:15 +0000 Subject: vtest status In-Reply-To: <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> Message-ID: <30034.1547071755@critter.freebsd.dk> -------- In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: Try the stuff I just committed. If you say "make vtest" you get no varnishsupport If you say "make varnishtest" and point the variable at your varnish source tree, you get varnish support. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 10 09:10:57 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Jan 2019 09:10:57 +0000 Subject: vtest status In-Reply-To: References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> Message-ID: <32119.1547111457@critter.freebsd.dk> -------- In message , Frederic Lecaille writes: >On 1/9/19 11:09 PM, Poul-Henning Kamp wrote: >> -------- >> In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: >> >> Try the stuff I just committed. >> >> If you say "make vtest" you get no varnishsupport >> >> If you say "make varnishtest" and point the variable at your >> varnish source tree, you get varnish support. > >Everything is OK. >Thank you a lot Poul-Henning. Cool. I'll update the README with some context... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 10 09:32:58 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Jan 2019 09:32:58 +0000 Subject: vtest status In-Reply-To: <4f28e66f-b12c-6192-7307-f88e6b2bc62e@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> <20190110054911.GA9693@haproxy.com> <4f28e66f-b12c-6192-7307-f88e6b2bc62e@haproxy.com> Message-ID: <32918.1547112778@critter.freebsd.dk> -------- In message <4f28e66f-b12c-6192-7307-f88e6b2bc62e at haproxy.com>, Frederic Lecaille writes: >As the python scripts run when compiling vtest is python2 compatible, >we can replace "python3" by "python" which points to python2 or >python3, depending on the distro. I did it slightly different, because some systems have given up on the "bare" python name. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 10 09:57:38 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Jan 2019 09:57:38 +0000 Subject: vtest status In-Reply-To: References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> <20190110054911.GA9693@haproxy.com> Message-ID: <33265.1547114258@critter.freebsd.dk> -------- In message , Frederic Lecaille writes: >> Indeed, it's much easier now :-) It's the first time I can build it. >> I had to use this since there are probably still options that the user >> has to tune : >> >> make CC='gcc -DHAVE_SYS_VFS_H' > >with > make CC='gcc -O2 -s -D_GNU_SOURCE -DHAVE_SYS_VFS_H' > >we do not have anymore these warnings: Better ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Jan 10 10:19:45 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Jan 2019 10:19:45 +0000 Subject: vtest status In-Reply-To: <6190b3ce-77db-5e6e-7c33-2a571517c9d8@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> <20190110054911.GA9693@haproxy.com> <33265.1547114258@critter.freebsd.dk> <6190b3ce-77db-5e6e-7c33-2a571517c9d8@haproxy.com> Message-ID: <33431.1547115585@critter.freebsd.dk> -------- In message <6190b3ce-77db-5e6e-7c33-2a571517c9d8 at haproxy.com>, Frederic Lecaille writes: >For instance on my FreeBSD 11 system, the config.h of varnish cache >defines _GNU_SOURCE. I truly hate and detest the autocrap tools[1], and that is just one of the many, many, many reasons why. Poul-Henning [1] See: https://queue.acm.org/detail.cfm?id=2349257 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From chandankhatri1 at gmail.com Tue Jan 15 17:50:00 2019 From: chandankhatri1 at gmail.com (chandan khatri) Date: Tue, 15 Jan 2019 09:50:00 -0800 Subject: Search engine query cache Message-ID: Hi All, We are trying to use Varnish as API accelerator in order to speed up the search engine query response time. After the required setup was done, we could see it working and caching the API calls to search engine but when we performed stress testing we ran into connection time out exceptions. We tried changing max connection and timeout configuration but it didn't work; moreover, we aren't able to see any error logs in varnish logs the exception comes in the client application logs only. We are stuck and unable to progress any further. Any help would be appreciated. Thanks Chandan -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jan 28 12:54:04 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 28 Jan 2019 12:54:04 +0000 Subject: VMOD havoc generating patch Message-ID: <84471.1548680044@critter.freebsd.dk> Ticket 2810 is about the names generated by vmodtool and vcc, and while there is a good intellectual argument for getting it right, I am a little bit worried about how much havoc that causes. This is a WIP patch headed in that direction, and I would like to hear input from VMOD writers. Ideally with this stuff finished, VMOD writers can version their vmods using $Prefix and you will then be able to import multiple different versions of the same VMOD in the same VCL. Not sure that is a good thing to do, but it proves that the name-space issue is solved. See the changes to the in-tree vmods for how this will look for you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -------------- next part -------------- A non-text attachment was scrubbed... Name: _patch_vmodname.txt Type: text/x-diff Size: 39010 bytes Desc: _patch_vmodname.txt URL: From flecaille at haproxy.com Wed Jan 9 21:17:58 2019 From: flecaille at haproxy.com (Frederic Lecaille) Date: Wed, 09 Jan 2019 21:17:58 -0000 Subject: vtest status In-Reply-To: <13120.1547030174@critter.freebsd.dk> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> Message-ID: <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> On 1/9/19 11:36 AM, Poul-Henning Kamp wrote: > -------- > In message <58d74416-8e0f-4a35-bb7c-67f02a680fdc at haproxy.com>, Frederic Lecaille writes: > >> I hope everything is going well on your side. > > Well, getting better: One of my close friends died from stomach-cancer > right before X-mas and that threw all plans askew. > >> So, if you need some help to make vtest project progress, please >> do not hesitate to ask. > > I think what we need most right now, is to decide what shape vtest > should take? Yes! > I want to stress that I want this to be a collective decision, > so don't take anything I write here as edict or diktat. > > Personally I am not very keen on turning vtest a "real" project > with releases, package-building and all that, because it would cause > me a lot of work which I don't think brings enough advantages. > > The problem for me is that vtc_varnish has a very incestuos > relationship with varnish internals, internals which we do not want > to turn into documented or even open APIs, and that means that > vtc_varnish and varnishd must match versions. > > A stand-alone vtest-package would either need to be compiled against > a specific version of varnish, or have some way to dynamically load > vtc_varnish from from the varnish source/package it is being used > against. > > But that just moves the problem to the other side of the line, where > we need to open the internals of vtest up as a documented and > versioned API... > > Some day (H3?) all that work may make sense, but I don't feel we > are there yet, at least not as far as cost/benefit is concerned. > > My suggestion for now, is to let vtest live as a "source code > library" on github and not build and distribute it as stand-alone > packages. Currently, vtest convert.sh script make copies of lib/libvarnish/*.c which are already compiled when compiling varnish sources providing lib/libvarnish.a library. Could not this vtest library be compiled against lib/libvarnish.a library? > Instead it will be up to the projects which use it to import > and build in their own projects. > > That way HAproxy and leave vtc_varnish out of their compilation so > varnish does not become a build-dependency (or you can conditionally > compile vtc_varnish in, if it is already there.) > > And we can compile it in Varnish including vtc_varnish, and include > vtc_haproxy in similar fashion. (actually, compilation of > vtc_haproxy does not need haproxy to be installed, does it ?) Of course not, it does not. > We should still provide a Makefile in the vtest github project which > compiles as much as possible (ie: vtc_varnish if it can find varnish > installed), that will make work on the shared sources easier for > all of us. Yes, I agree. > If we decide to do things that way, maybe you should call your > compiled version something like "hatest", while we stick with > "varnishtest", so we can reserve the "vtest" name for the future > runtime-extensible all-singing-and-dancing thing ? All these information sound fair to me. As far as we do not have to make copies of file from varnish sources to compile vtest this would help to its maintenance. Fred. From wtarreau at haproxy.com Thu Jan 10 05:49:13 2019 From: wtarreau at haproxy.com (Willy TARREAU) Date: Thu, 10 Jan 2019 05:49:13 -0000 Subject: vtest status In-Reply-To: <30034.1547071755@critter.freebsd.dk> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> Message-ID: <20190110054911.GA9693@haproxy.com> Hi Poul-Henning! On Wed, Jan 09, 2019 at 10:09:15PM +0000, Poul-Henning Kamp wrote: > -------- > In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: > > Try the stuff I just committed. > > If you say "make vtest" you get no varnishsupport > > If you say "make varnishtest" and point the variable at your > varnish source tree, you get varnish support. Indeed, it's much easier now :-) It's the first time I can build it. I had to use this since there are probably still options that the user has to tune : make CC='gcc -DHAVE_SYS_VFS_H' I think we can plan on adding a CFLAGS or whatever variable and enumerate the most common defines that users may need. They're all supposed to be sufficiently autonomous developers to be able to figure what they need to pass to build it. We also need to make this "python3" thing a variable in the makefile. On my previous distro, it was called "python". Same, developers will just have to force the variable if they want. Everything looks good this way, I'll spread the word here to the team. We may propose you some patches for the few points above, and after this I think we can update our doc in haproxy to refer to the vtest repo and suggest how to build it. Thank you! Willy From flecaille at haproxy.com Thu Jan 10 08:49:14 2019 From: flecaille at haproxy.com (Frederic Lecaille) Date: Thu, 10 Jan 2019 08:49:14 -0000 Subject: vtest status In-Reply-To: <28833.1547070563@critter.freebsd.dk> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <28833.1547070563@critter.freebsd.dk> Message-ID: <269adc3b-85d3-2c71-4e30-9ea2bcd8f524@haproxy.com> On 1/9/19 10:49 PM, Poul-Henning Kamp wrote: > -------- > In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: > >>> My suggestion for now, is to let vtest live as a "source code >>> library" on github and not build and distribute it as stand-alone >>> packages. >> >> Currently, vtest convert.sh script make copies of lib/libvarnish/*.c >> which are already compiled when compiling varnish sources providing >> lib/libvarnish.a library. > > The convert.sh script is really only meant to show me what the > difference is between the copy of vtest in the varnish cache > project and in the vtest project. Ok. >> Could not this vtest library be compiled against lib/libvarnish.a >> library? to be more accurate: lib/libvarnish/libvarnish.a > The problem is that if you install a varnish package you do not > have libvarnish.a, it is an internal static library. Yes, I know that lib/libvarnishapi is exported. I thought we would still have to compile the varnish sources before compiling vtest, and give to this latter the path to lib/libvarnish/libvarnish.a. Anyway if we do not need the varnish sources anymore to compile vtest this means varnish is perfectly modularized. Great! From flecaille at haproxy.com Thu Jan 10 09:09:13 2019 From: flecaille at haproxy.com (Frederic Lecaille) Date: Thu, 10 Jan 2019 09:09:13 -0000 Subject: vtest status In-Reply-To: <30034.1547071755@critter.freebsd.dk> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> Message-ID: On 1/9/19 11:09 PM, Poul-Henning Kamp wrote: > -------- > In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: > > Try the stuff I just committed. > > If you say "make vtest" you get no varnishsupport > > If you say "make varnishtest" and point the variable at your > varnish source tree, you get varnish support. > Everything is OK. Thank you a lot Poul-Henning. Fred From flecaille at haproxy.com Thu Jan 10 09:12:01 2019 From: flecaille at haproxy.com (Frederic Lecaille) Date: Thu, 10 Jan 2019 09:12:01 -0000 Subject: vtest status In-Reply-To: <20190110054911.GA9693@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> <20190110054911.GA9693@haproxy.com> Message-ID: <4f28e66f-b12c-6192-7307-f88e6b2bc62e@haproxy.com> On 1/10/19 6:49 AM, Willy TARREAU wrote: > Hi Poul-Henning! > > On Wed, Jan 09, 2019 at 10:09:15PM +0000, Poul-Henning Kamp wrote: >> -------- >> In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: >> >> Try the stuff I just committed. >> >> If you say "make vtest" you get no varnishsupport >> >> If you say "make varnishtest" and point the variable at your >> varnish source tree, you get varnish support. > > Indeed, it's much easier now :-) It's the first time I can build it. > I had to use this since there are probably still options that the user > has to tune : > > make CC='gcc -DHAVE_SYS_VFS_H' > > I think we can plan on adding a CFLAGS or whatever variable and enumerate > the most common defines that users may need. They're all supposed to be > sufficiently autonomous developers to be able to figure what they need > to pass to build it. > > We also need to make this "python3" thing a variable in the makefile. On > my previous distro, it was called "python". Same, developers will just > have to force the variable if they want. As the python scripts run when compiling vtest is python2 compatible, we can replace "python3" by "python" which points to python2 or python3, depending on the distro. From flecaille at haproxy.com Thu Jan 10 09:21:15 2019 From: flecaille at haproxy.com (Frederic Lecaille) Date: Thu, 10 Jan 2019 09:21:15 -0000 Subject: vtest status In-Reply-To: <20190110054911.GA9693@haproxy.com> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> <20190110054911.GA9693@haproxy.com> Message-ID: On 1/10/19 6:49 AM, Willy TARREAU wrote: > Hi Poul-Henning! > > On Wed, Jan 09, 2019 at 10:09:15PM +0000, Poul-Henning Kamp wrote: >> -------- >> In message <1ca72b15-d581-4556-713a-a95106aa2d09 at haproxy.com>, Frederic Lecaille writes: >> >> Try the stuff I just committed. >> >> If you say "make vtest" you get no varnishsupport >> >> If you say "make varnishtest" and point the variable at your >> varnish source tree, you get varnish support. > > Indeed, it's much easier now :-) It's the first time I can build it. > I had to use this since there are probably still options that the user > has to tune : > > make CC='gcc -DHAVE_SYS_VFS_H' with make CC='gcc -O2 -s -D_GNU_SOURCE -DHAVE_SYS_VFS_H' we do not have anymore these warnings: src/vtc_process.c:652:11: warning: implicit declaration of function ?posix_openpt? [-Wimplicit-function-declaration] master = posix_openpt(O_RDWR|O_NOCTTY); ^~~~~~~~~~~~ In file included from src/vtc.h:41:0, from src/vtc_process.c:49: src/vtc_process.c:654:5: warning: implicit declaration of function ?grantpt? [-Wimplicit-function-declaration] AZ(grantpt(master)); ^ lib/vas.h:61:8: note: in definition of macro ?assert? if (!(e)) { \ ^ src/vtc_process.c:654:2: note: in expansion of macro ?AZ? AZ(grantpt(master)); ^~ src/vtc_process.c:655:5: warning: implicit declaration of function ?unlockpt? [-Wimplicit-function-declaration] AZ(unlockpt(master)); ^ lib/vas.h:61:8: note: in definition of macro ?assert? if (!(e)) { \ ^ src/vtc_process.c:655:2: note: in expansion of macro ?AZ? AZ(unlockpt(master)); ^~ src/vtc_process.c:656:14: warning: implicit declaration of function ?ptsname? [-Wimplicit-function-declaration] slavename = ptsname(master); ^~~~~~~ src/vtc_process.c:656:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion] slavename = ptsname(master); ^ lib/vfil.c: In function ?VFIL_fsinfo?: lib/vfil.c:198:16: error: storage size of ?fsst? isn?t known struct statfs fsst; From flecaille at haproxy.com Thu Jan 10 10:10:09 2019 From: flecaille at haproxy.com (Frederic Lecaille) Date: Thu, 10 Jan 2019 10:10:09 -0000 Subject: vtest status In-Reply-To: <33265.1547114258@critter.freebsd.dk> References: <3343b0af-857e-333c-4d1f-26b8601c977c@haproxy.com> <1506.1545129065@critter.freebsd.dk> <58d74416-8e0f-4a35-bb7c-67f02a680fdc@haproxy.com> <13120.1547030174@critter.freebsd.dk> <1ca72b15-d581-4556-713a-a95106aa2d09@haproxy.com> <30034.1547071755@critter.freebsd.dk> <20190110054911.GA9693@haproxy.com> <33265.1547114258@critter.freebsd.dk> Message-ID: <6190b3ce-77db-5e6e-7c33-2a571517c9d8@haproxy.com> On 1/10/19 10:57 AM, Poul-Henning Kamp wrote: > -------- > In message , Frederic Lecaille writes: > >>> Indeed, it's much easier now :-) It's the first time I can build it. >>> I had to use this since there are probably still options that the user >>> has to tune : >>> >>> make CC='gcc -DHAVE_SYS_VFS_H' >> >> with >> make CC='gcc -O2 -s -D_GNU_SOURCE -DHAVE_SYS_VFS_H' >> >> we do not have anymore these warnings: > > Better ? > Yes, I have seen this commit: https://github.com/vtest/VTest/commit/9433a1f8fb8687465dd611cb0a941f0d7865e707 But I am not sure that _GNU_SOURCE may be enabled only Linux systems. To me it is Glibc specific. For instance on my FreeBSD 11 system, the config.h of varnish cache defines _GNU_SOURCE. Nothing really important, vtest compiles like a charm. Thanks.