Actually, we can successfully compile the latest 1.7 on the same Solaris
setup, without USE_PTHREAD_PSHARED.
You're right about the patch, though; it seems unnecessary with that flag.
Thanks!
On Saturday, 21 July 2018, 10:07:41 am AEST, Olivier Houchard
wrote:
My patch won't be
Hi,
On Sat, Jul 21, 2018 at 12:51:53AM +0200, Lukas Tribus wrote:
> Hello,
>
> On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote:
> >
> > Hi LuKas,
> >
> > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> > > Hello Oliver,
> > >
> > > On Fri, 20 Jul 2018 at 11:55, Olivier
Hello,
On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote:
>
> Hi LuKas,
>
> On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> > Hello Oliver,
> >
> > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
> > wrote:
> > >
> > > Hi,
> > >
> > > On Fri, Jul 20, 2018 at 12:22:20AM +,
Hi LuKas,
On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> Hello Oliver,
>
> On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
> wrote:
> >
> > Hi,
> >
> > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> > > So...is there a way to adapt this patch so it won't cause random
Hello Oliver,
On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
wrote:
>
> Hi,
>
> On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> > So...is there a way to adapt this patch so it won't cause random SSL
errors and is suitable to apply to the trunk? We don't really want to run a
customised
Hi,
On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> So...is there a way to adapt this patch so it won't cause random SSL errors
> and is suitable to apply to the trunk? We don't really want to run a
> customised build in production...
You don't need the patch, just using
So...is there a way to adapt this patch so it won't cause random SSL errors
and is suitable to apply to the trunk? We don't really want to run a customised
build in production...
On Wednesday, 18 July 2018, 10:45:38 pm AEST, Olivier Houchard
wrote:
Hi,
On Wed, Jul 18, 2018 at
Hi,
On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote:
> Mea culpa, I applied the patch incorrectly. After fixing that, I can
> successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes'
> (although from what Olivier said, I probably shouldn't do that). On
> Wednesday,
Mea culpa, I applied the patch incorrectly. After fixing that, I can
successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes'
(although from what Olivier said, I probably shouldn't do that). On
Wednesday, 18 July 2018, 12:10:57 pm AEST, Thrawn
wrote:
We always clean
We always clean before building. The shell script I use is currently:
MAKE=/usr/sfw/bin/gmake$MAKE clean$MAKE USE_STATIC_PCRE=1 ARCH=native
TARGET=solaris PCREDIR=../pcre USE_THREAD= USE_PTHREAD_PSHARED=yes
And after applying the patch (and USE_PTHREAD_PSHARED=yes as you can see), that
builds
Hi again,
On Tue, Jul 17, 2018 at 01:55:33PM +0200, Olivier Houchard wrote:
> Hi Lukas,
>
> On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote:
> > On Tue, 17 Jul 2018 at 01:09, Thrawn
> > wrote:
> > >
> > > Ah, indeed, the GCC version provided on our server is 3.4.3. But the
> > >
Hi Lukas,
On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote:
> On Tue, 17 Jul 2018 at 01:09, Thrawn wrote:
> >
> > Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme
> > on https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can
> > the build
On Tue, 17 Jul 2018 at 01:09, Thrawn wrote:
>
> Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme
> on https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can
> the build be changed to continue supporting older GCC, or do the docs need an
> update?
Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme on
https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can the
build be changed to continue supporting older GCC, or do the docs need an
update?
Thanks for the quick help.
On Monday, 16 July 2018,
Hi,
On Mon, Jul 16, 2018 at 01:12:18AM +, Thrawn wrote:
> Update: If I disable threading with
> USE_THREAD=
> then the build gets much further, but still fails eventually with:
> gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o
> ebtree/eb32tree.o ebtree/eb64tree.o
Hello,
On Mon, 16 Jul 2018 at 03:12, Thrawn wrote:
>
> Update: If I disable threading with
>
> USE_THREAD=
>
> then the build gets much further, but still fails eventually with:
>
> gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o
> ebtree/eb32tree.o ebtree/eb64tree.o
Update: If I disable threading with
USE_THREAD=
then the build gets much further, but still fails eventually with:
gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o
ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o
ebtree/ebimtree.o ebtree/ebistree.o
My workplace is using HAProxy on Solaris (uname -a output: SunOS 5.10
Generic_150400-49 sun4v sparc sun4v), and we can build up to 1.7.11
successfully, but attempting to build 1.8 fails.
> MAKE=/usr/sfw/bin/gmake> $MAKE cleanrm -f *.[oas] src/*.[oas] ebtree/*.[oas]
> haproxy test .build_opts
18 matches
Mail list logo
