Re: lang/gerbil build failures on i386

2019-08-10 Thread Stuart Henderson 
On 2019/08/09 21:52, Timo Myyr=E4 wrote:
> Hmm, lets see what the tests itself tell.
> Stuart, Could you try following diff to disable the TAGS generation.
> Without tags the build should work and test would be runnable.

Everything passes. Output below:


Test suite: test :std/generic support
Test case: test default dispatch
=2E.. check (generic-dispatch my-generic 1 2) is equal? to #f
=2E.. 1 checks OK
Test case: test multimethod dispatch
=2E.. check (generic-dispatch my-generic 1 2) is equal? to (number+ 1 2)
=2E.. check (generic-dispatch my-generic a b) is equal? to (string+ "a" "b")
=2E.. 2 checks OK
Test case: test specialization
=2E.. check (generic-dispatch my-generic 1 2) is equal? to (fixnum+ 1 2)
=2E.. check (generic-dispatch my-generic 1. 2.) is equal? to (number+ 1. 2.)
=2E.. 2 checks OK
Test case: test user type dispatch
=2E.. check (generic-dispatch my-generic (make-A 1) (make-A 2)) is equal? t=
o (A+ 1 2)
=2E.. 1 checks OK
=2E.. All tests OK
Test suite: test :std/generic macros
Test case: test default dispatch
=2E.. check (my-add 1 2) is equal? to #f
=2E.. 1 checks OK
Test case: test multimethod dispatch
=2E.. check (my-add 1 2) is equal? to (number+ 1 2)
=2E.. check (my-add a b) is equal? to (string+ "a" "b")
=2E.. 2 checks OK
Test case: test specialization
=2E.. check (my-add 1 2) is equal? to (fixnum+ 1 2)
=2E.. check (my-add 1. 2.) is equal? to (number+ 1. 2.)
=2E.. 2 checks OK
Test case: test user type dispatch
=2E.. check (my-add (make-A 1) (make-A 2)) is equal? to (A+ 1 2)
=2E.. 1 checks OK
=2E.. All tests OK
Test suite: test :std/coroutine
Test case: test coroutine
=2E.. check (collect (coroutine 1-to-n 10)) is equal? to (1 2 3 4 5 6 7 8 9=
 10)
=2E.. 1 checks OK
Test case: test cothread
=2E.. check (collect (cothread 1-to-n 10)) is equal? to (1 2 3 4 5 6 7 8 9 =
10)
=2E.. 1 checks OK
=2E.. All tests OK
Test suite: test :std/iter
Test case: test imperative for
=2E.. check (test-for-1) outputs "1\n2\n3\n"
=2E.. check (test-for-2) outputs "1 a\n2 b\n3 c\n"
=2E.. check (test-for-3) outputs "0\n1\n2\n"
=2E.. check (test-for-4) outputs "3\n4\n5\n"
=2E.. check (test-for-5) outputs "3\n5\n7\n"
=2E.. check (test-for-6) outputs "0\n1\n2\n"
=2E.. 6 checks OK
Test case: test folding macros
=2E.. check (test-for/collect-0) is equal? to (2 4 6)
=2E.. check (test-for/collect-1) is equal? to ((1 . a) (2 . b) (3 . c))
=2E.. check (test-for/collect-2) is equal? to ((1 . a) (2 . b) (3 . c) (4 .=
 d))
=2E.. check (test-for/collect-3) is equal? to (0 1 2)
=2E.. check (test-for/fold-1) is equal? to (3 2 1)
=2E.. check (test-for/fold-2) is equal? to (3 c 2 b 1 a)
=2E.. 6 checks OK
Test case: test iter xforms
=2E.. check (test-xform-when) is equal? to (1 3)
=2E.. check (test-xform-unless) is equal? to (0 2 4)
=2E.. 2 checks OK
=2E.. All tests OK
Test suite: test :std/amb
Test case: solve dwelling puzzle
=2E.. check (solve-dwelling-puzzle) is equal? to ((baker 3) (cooper 2) (fle=
tcher 4) (miller 5) (smith 1))
=2E.. 1 checks OK
=2E.. All tests OK
Test suite: test :std/event
Test case: test wait
=2E.. check (wait thr1 1) is equal? to #
=2E.. check (wait thr2 1) is equal? to #f
=2E.. check (wait thr2 2) is equal? to #
=2E.. check (wait sel3 2) is equal? to (# . #)
=2E.. 4 checks OK
Test case: test select
=2E.. check (select (@list thr1 thr2) 1) is equal? to #
=2E.. check (select (@list thr2 (cons mx3 cv3)) 2) is equal? to #
=2E.. check (select (@list sel3 sel4) 0) is equal? to #f
=2E.. check (select (@list sel3 sel4) 2) is equal? to (# . #)
=2E.. 4 checks OK
Test case: test sync selectors
=2E.. check (sync 1) is equal? to #f
=2E.. check (sync thr1 1) is equal? to #
=2E.. check (sync thr2 1) is equal? to #f
=2E.. check (sync thr2 2) is equal? to #
=2E.. check (sync (cons mx3 cv3)) is equal? to (# . #)
=2E.. 5 checks OK
Test case: test sync events
=2E.. check (sync never-evt 0) is equal? to #f
=2E.. check (sync always-evt 0) is equal? to #
=2E.. check (sync (handle-evt 1 (lambda (_) 'timeout))) is equal? to timeout
=2E.. check (sync (choice-evt never-evt always-evt)) is equal? to #
=2E.. check (sync (choice-evt never-evt (handle-evt 1 (lambda (_) 'timeout)=
))) is equal? to timeout
=2E.. check (sync (handle-evt (choice-evt never-evt (handle-evt 1 (lambda (=
_) 'timeout))) values)) is equal? to timeout
=2E.. 6 checks OK
Test case: test sync input ports
=2E.. check (sync /dev/null) is equal? to #
=2E.. check (sync srv) is equal? to #
=2E.. check (sync in) is equal? to #
=2E.. 3 checks OK
=2E.. All tests OK
Test suite: test :std/text/csv
Test case: test-empty-fields
=2E.. check (csv->lines 1,2,3
,2,3
1,,3
1,2,
) is equal? to (("1" "2" "3") ("" "2" "3") ("1" "" "3") ("1" "2" ""))
=2E.. check (lines->csv '((1 2 3) ( 2 3) (1  3) (1 2 ))) is equal? to "1,2,=
3\n,2,3\n1,,3\n1,2,\n"
=2E.. 2 checks OK
Test case: test-happy-ending
=2E.. check (csv->lines one,two,three,) is equal? to (("one" "two" "three" =
""))
=2E.. check (lines->csv '((one two three ))) is equal? to "one,two,three,\n"
=2E.. check (csv->lines one,two,th

Re: lang/gerbil build failures on i386

2019-08-09 Thread Timo Myyrä 
Juan Francisco Cantero Hurtado  writes:

> On Thu, Aug 08, 2019 at 11:41:36PM +0100, Stuart Henderson wrote:
>
>> On 2019/08/05 19:49, Juan Francisco Cantero Hurtado wrote:
>> > On Mon, Aug 05, 2019 at 06:23:00PM +0100, Stuart Henderson wrote:
>> > > On 2019/08/05 18:58, Jeremie Courreges-Anglas wrote:
>> > > > On Mon, Aug 05 2019, Stuart Henderson  wrote:
>> > > > > On 2019/08/05 17:25, Timo Myyrä wrote:
>> > > > >> Juan Francisco Cantero Hurtado  writes:
>> > > > 
>> > > > [...]
>> > > > 
>> > > > >> > Could you test this patch?.
>> > > > >> >
>> > > > >> >
>> > > > >> > diff --git Makefile Makefile
>> > > > >> > index 88a777f7c30..7547cf59c6c 100644
>> > > > >> > --- Makefile
>> > > > >> > +++ Makefile
>> > > > >> > @@ -39,7 +39,8 @@ NO_TEST =   Yes
>> > > > >> >  GERBIL_ROOT =${PREFIX}/gerbil
>> > > > >> >  
>> > > > >> >  do-build:
>> > > > >> > - cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
>> > > > >> > ./build.sh
>> > > > >> > + cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
>> > > > >> > + ${SETENV} ${MAKE_ENV} ./build.sh
>> > > > >> >  
>> > > > >> >  do-install:
>> > > > >> >   ${INSTALL_DATA_DIR} ${GERBIL_ROOT}
>> > > > >
>> > > > > Trying that in my next build (though it would seem odd for it to 
>> > > > > require
>> > > > > more stack on one machine than another?)
>> > > 
>> > > Unsurprisingly it didn't help.
>> > > 
>> > > > Or maybe amd64.p and exopi don't use the same limits (login.conf)?
>> > > > naddy, ajacoutot?
>> > > 
>> > > On i386 I did copy login.conf to the new machines.
>> > > 
>> > > Same results building lang/gerbil with ports-gcc.
>> > 
>> > Build gambit with this patch and then try to build gerbil:
>> > 
>> > 
>> > diff --git Makefile Makefile
>> > index 9202dbfc8db..e6184545f60 100644
>> > --- Makefile
>> > +++ Makefile
>> > @@ -3,6 +3,7 @@
>> >  COMMENT=  complete, efficient and reliable implementation of Scheme
>> >  
>> >  V=4.9.3
>> > +REVISION= 0
>> >  DISTNAME= gambit-v${V:S/./_/g}
>> >  PKGNAME=  gambit-$V
>> >  API_V=${V:R:S/./0/}00${V:E}
>> > @@ -20,8 +21,13 @@ PERMIT_PACKAGE= Yes
>> >  MASTER_SITES= 
>> > http://www.iro.umontreal.ca/~gambit/download/gambit/v${V:R}/source/
>> >  EXTRACT_SUFX= .tgz
>> >  
>> > +COMPILER= ports-gcc
>> > +COMPILER_LANGS=   c
>> > +
>> >  WANTLIB +=c crypto m ssl util
>> >  
>> > +RUN_DEPENDS=  lang/gcc/${MODGCC4_VERSION}
>> > +
>> >  CONFIGURE_STYLE=gnu
>> >  CONFIGURE_ARGS+=--disable-cplusplus \
>> >--disable-absolute-shared-libs \
>> > @@ -42,6 +48,10 @@ do-build:
>> >ulimit -s 12288 && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
>> >${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} ${ALL_TARGET}
>> >  
>> > +post-build:
>> > +  sed -i 's/C_COMPILER=\"cc\"/C_COMPILER=\"egcc\"/' 
>> > ${WRKSRC}/bin/gambcomp-C.unix
>> > +  sed -i 's/C_PREPROC=\"cc -E\"/C_PREPROC=\"egcc -E\"/' 
>> > ${WRKSRC}/bin/gambcomp-C.unix
>> > +
>> >  do-test:
>> >cd ${WRKSRC}/tests && ${SETENV} ${TEST_ENV} ${MAKE_PROGRAM} \
>> >${TEST_FLAGS} -f makefile ${TEST_TARGET}
>> > 
>> 
>> Same problem. I've tried all combinations:
>> 
>> gambit   gerbil
>> --   --
>> clanggcc
>> gcc  clang
>> gcc  gcc
>
> Thanks for taking the time to test all the combinations. I'm out of
> ideas, so the only option would be disable the tags as upstream and Timo
> suggested. Could you build gambit and gerbil with symbols and send me
> the pobj directories of both ports?.
>
> Feel free to mark the port as broken if you want.

Hmm, lets see what the tests itself tell.
Stuart, Could you try following diff to disable the TAGS generation.
Without tags the build should work and test would be runnable.

Timo

Index: patches/patch-src_build_sh
===
RCS file: patches/patch-src_build_sh
diff -N patches/patch-src_build_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_build_sh  9 Aug 2019 18:50:18 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/build.sh
+--- src/build.sh.orig
 src/build.sh
+@@ -197,7 +197,7 @@ build_gerbil() {
+   build_lang   || die
+   build_r7rs_large || die
+   build_tools  || die
+-  build_tags   || die
++#  build_tags   || die
+ }
+ 
+ ## handling command line
Index: pkg/PLIST
===
RCS file: /cvs/ports/lang/gerbil/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST
--- pkg/PLIST   10 Feb 2019 18:01:30 -  1.3
+++ pkg/PLIST   9 Aug 2019 18:50:18 -
@@ -1551,7 +1551,6 @@ gerbil/lib/std/xml/sxpath.ssxi.ss
 @bin gerbil/lib/std/xml/sxpath__rt.o1
 @bin gerbil/lib/std/xml__rt.o1
 gerbil/src/
-gerbil/src/TAGS
 gerbil/src/bootstrap/
 gerbil/src/bootstrap/gerbil/
 gerbil/src/bootstrap/gerbil/compiler/

Re: lang/gerbil build failures on i386

2019-08-09 Thread Juan Francisco Cantero Hurtado 
On Thu, Aug 08, 2019 at 11:41:36PM +0100, Stuart Henderson wrote:
> On 2019/08/05 19:49, Juan Francisco Cantero Hurtado wrote:
> > On Mon, Aug 05, 2019 at 06:23:00PM +0100, Stuart Henderson wrote:
> > > On 2019/08/05 18:58, Jeremie Courreges-Anglas wrote:
> > > > On Mon, Aug 05 2019, Stuart Henderson  wrote:
> > > > > On 2019/08/05 17:25, Timo Myyrä wrote:
> > > > >> Juan Francisco Cantero Hurtado  writes:
> > > > 
> > > > [...]
> > > > 
> > > > >> > Could you test this patch?.
> > > > >> >
> > > > >> >
> > > > >> > diff --git Makefile Makefile
> > > > >> > index 88a777f7c30..7547cf59c6c 100644
> > > > >> > --- Makefile
> > > > >> > +++ Makefile
> > > > >> > @@ -39,7 +39,8 @@ NO_TEST =Yes
> > > > >> >  GERBIL_ROOT = ${PREFIX}/gerbil
> > > > >> >  
> > > > >> >  do-build:
> > > > >> > -  cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
> > > > >> > ./build.sh
> > > > >> > +  cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> > > > >> > +  ${SETENV} ${MAKE_ENV} ./build.sh
> > > > >> >  
> > > > >> >  do-install:
> > > > >> >${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> > > > >
> > > > > Trying that in my next build (though it would seem odd for it to 
> > > > > require
> > > > > more stack on one machine than another?)
> > > 
> > > Unsurprisingly it didn't help.
> > > 
> > > > Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> > > > naddy, ajacoutot?
> > > 
> > > On i386 I did copy login.conf to the new machines.
> > > 
> > > Same results building lang/gerbil with ports-gcc.
> > 
> > Build gambit with this patch and then try to build gerbil:
> > 
> > 
> > diff --git Makefile Makefile
> > index 9202dbfc8db..e6184545f60 100644
> > --- Makefile
> > +++ Makefile
> > @@ -3,6 +3,7 @@
> >  COMMENT=   complete, efficient and reliable implementation of Scheme
> >  
> >  V= 4.9.3
> > +REVISION=  0
> >  DISTNAME=  gambit-v${V:S/./_/g}
> >  PKGNAME=   gambit-$V
> >  API_V= ${V:R:S/./0/}00${V:E}
> > @@ -20,8 +21,13 @@ PERMIT_PACKAGE=  Yes
> >  MASTER_SITES=  
> > http://www.iro.umontreal.ca/~gambit/download/gambit/v${V:R}/source/
> >  EXTRACT_SUFX=  .tgz
> >  
> > +COMPILER=  ports-gcc
> > +COMPILER_LANGS=c
> > +
> >  WANTLIB += c crypto m ssl util
> >  
> > +RUN_DEPENDS=   lang/gcc/${MODGCC4_VERSION}
> > +
> >  CONFIGURE_STYLE=gnu
> >  CONFIGURE_ARGS+=--disable-cplusplus \
> > --disable-absolute-shared-libs \
> > @@ -42,6 +48,10 @@ do-build:
> > ulimit -s 12288 && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
> > ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} ${ALL_TARGET}
> >  
> > +post-build:
> > +   sed -i 's/C_COMPILER=\"cc\"/C_COMPILER=\"egcc\"/' 
> > ${WRKSRC}/bin/gambcomp-C.unix
> > +   sed -i 's/C_PREPROC=\"cc -E\"/C_PREPROC=\"egcc -E\"/' 
> > ${WRKSRC}/bin/gambcomp-C.unix
> > +
> >  do-test:
> > cd ${WRKSRC}/tests && ${SETENV} ${TEST_ENV} ${MAKE_PROGRAM} \
> > ${TEST_FLAGS} -f makefile ${TEST_TARGET}
> > 
> 
> Same problem. I've tried all combinations:
> 
> gambitgerbil
> ----
> clang gcc
> gcc   clang
> gcc   gcc

Thanks for taking the time to test all the combinations. I'm out of
ideas, so the only option would be disable the tags as upstream and Timo
suggested. Could you build gambit and gerbil with symbols and send me
the pobj directories of both ports?.

Feel free to mark the port as broken if you want.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: lang/gerbil build failures on i386

2019-08-08 Thread Stuart Henderson 
On 2019/08/05 19:49, Juan Francisco Cantero Hurtado wrote:
> On Mon, Aug 05, 2019 at 06:23:00PM +0100, Stuart Henderson wrote:
> > On 2019/08/05 18:58, Jeremie Courreges-Anglas wrote:
> > > On Mon, Aug 05 2019, Stuart Henderson  wrote:
> > > > On 2019/08/05 17:25, Timo Myyrä wrote:
> > > >> Juan Francisco Cantero Hurtado  writes:
> > > 
> > > [...]
> > > 
> > > >> > Could you test this patch?.
> > > >> >
> > > >> >
> > > >> > diff --git Makefile Makefile
> > > >> > index 88a777f7c30..7547cf59c6c 100644
> > > >> > --- Makefile
> > > >> > +++ Makefile
> > > >> > @@ -39,7 +39,8 @@ NO_TEST =  Yes
> > > >> >  GERBIL_ROOT =   ${PREFIX}/gerbil
> > > >> >  
> > > >> >  do-build:
> > > >> > -cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
> > > >> > ./build.sh
> > > >> > +cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> > > >> > +${SETENV} ${MAKE_ENV} ./build.sh
> > > >> >  
> > > >> >  do-install:
> > > >> >  ${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> > > >
> > > > Trying that in my next build (though it would seem odd for it to require
> > > > more stack on one machine than another?)
> > 
> > Unsurprisingly it didn't help.
> > 
> > > Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> > > naddy, ajacoutot?
> > 
> > On i386 I did copy login.conf to the new machines.
> > 
> > Same results building lang/gerbil with ports-gcc.
> 
> Build gambit with this patch and then try to build gerbil:
> 
> 
> diff --git Makefile Makefile
> index 9202dbfc8db..e6184545f60 100644
> --- Makefile
> +++ Makefile
> @@ -3,6 +3,7 @@
>  COMMENT= complete, efficient and reliable implementation of Scheme
>  
>  V=   4.9.3
> +REVISION=0
>  DISTNAME=gambit-v${V:S/./_/g}
>  PKGNAME= gambit-$V
>  API_V=   ${V:R:S/./0/}00${V:E}
> @@ -20,8 +21,13 @@ PERMIT_PACKAGE=Yes
>  MASTER_SITES=
> http://www.iro.umontreal.ca/~gambit/download/gambit/v${V:R}/source/
>  EXTRACT_SUFX=.tgz
>  
> +COMPILER=ports-gcc
> +COMPILER_LANGS=  c
> +
>  WANTLIB +=   c crypto m ssl util
>  
> +RUN_DEPENDS= lang/gcc/${MODGCC4_VERSION}
> +
>  CONFIGURE_STYLE=gnu
>  CONFIGURE_ARGS+=--disable-cplusplus \
>   --disable-absolute-shared-libs \
> @@ -42,6 +48,10 @@ do-build:
>   ulimit -s 12288 && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
>   ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} ${ALL_TARGET}
>  
> +post-build:
> + sed -i 's/C_COMPILER=\"cc\"/C_COMPILER=\"egcc\"/' 
> ${WRKSRC}/bin/gambcomp-C.unix
> + sed -i 's/C_PREPROC=\"cc -E\"/C_PREPROC=\"egcc -E\"/' 
> ${WRKSRC}/bin/gambcomp-C.unix
> +
>  do-test:
>   cd ${WRKSRC}/tests && ${SETENV} ${TEST_ENV} ${MAKE_PROGRAM} \
>   ${TEST_FLAGS} -f makefile ${TEST_TARGET}
> 

Same problem. I've tried all combinations:

gambit  gerbil
--  --
clang   gcc
gcc clang
gcc gcc

Re: lang/gerbil build failures on i386

2019-08-06 Thread Antoine Jacoutot 
On Mon, Aug 05, 2019 at 06:58:06PM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, Aug 05 2019, Stuart Henderson  wrote:
> > On 2019/08/05 17:25, Timo Myyrä wrote:
> >> Juan Francisco Cantero Hurtado  writes:
> 
> [...]
> 
> >> > Could you test this patch?.
> >> >
> >> >
> >> > diff --git Makefile Makefile
> >> > index 88a777f7c30..7547cf59c6c 100644
> >> > --- Makefile
> >> > +++ Makefile
> >> > @@ -39,7 +39,8 @@ NO_TEST =  Yes
> >> >  GERBIL_ROOT =   ${PREFIX}/gerbil
> >> >  
> >> >  do-build:
> >> > -cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
> >> > ./build.sh
> >> > +cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> >> > +${SETENV} ${MAKE_ENV} ./build.sh
> >> >  
> >> >  do-install:
> >> >  ${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> >
> > Trying that in my next build (though it would seem odd for it to require
> > more stack on one machine than another?)
> 
> Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> naddy, ajacoutot?

I use the default login.conf.

-- 
Antoine

Re: lang/gerbil build failures on i386

2019-08-05 Thread Juan Francisco Cantero Hurtado 
On Mon, Aug 05, 2019 at 06:23:00PM +0100, Stuart Henderson wrote:
> On 2019/08/05 18:58, Jeremie Courreges-Anglas wrote:
> > On Mon, Aug 05 2019, Stuart Henderson  wrote:
> > > On 2019/08/05 17:25, Timo Myyrä wrote:
> > >> Juan Francisco Cantero Hurtado  writes:
> > 
> > [...]
> > 
> > >> > Could you test this patch?.
> > >> >
> > >> >
> > >> > diff --git Makefile Makefile
> > >> > index 88a777f7c30..7547cf59c6c 100644
> > >> > --- Makefile
> > >> > +++ Makefile
> > >> > @@ -39,7 +39,8 @@ NO_TEST =Yes
> > >> >  GERBIL_ROOT = ${PREFIX}/gerbil
> > >> >  
> > >> >  do-build:
> > >> > -  cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
> > >> > ./build.sh
> > >> > +  cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> > >> > +  ${SETENV} ${MAKE_ENV} ./build.sh
> > >> >  
> > >> >  do-install:
> > >> >${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> > >
> > > Trying that in my next build (though it would seem odd for it to require
> > > more stack on one machine than another?)
> 
> Unsurprisingly it didn't help.
> 
> > Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> > naddy, ajacoutot?
> 
> On i386 I did copy login.conf to the new machines.
> 
> Same results building lang/gerbil with ports-gcc.

Build gambit with this patch and then try to build gerbil:


diff --git Makefile Makefile
index 9202dbfc8db..e6184545f60 100644
--- Makefile
+++ Makefile
@@ -3,6 +3,7 @@
 COMMENT=   complete, efficient and reliable implementation of Scheme
 
 V= 4.9.3
+REVISION=  0
 DISTNAME=  gambit-v${V:S/./_/g}
 PKGNAME=   gambit-$V
 API_V= ${V:R:S/./0/}00${V:E}
@@ -20,8 +21,13 @@ PERMIT_PACKAGE=  Yes
 MASTER_SITES=  
http://www.iro.umontreal.ca/~gambit/download/gambit/v${V:R}/source/
 EXTRACT_SUFX=  .tgz
 
+COMPILER=  ports-gcc
+COMPILER_LANGS=c
+
 WANTLIB += c crypto m ssl util
 
+RUN_DEPENDS=   lang/gcc/${MODGCC4_VERSION}
+
 CONFIGURE_STYLE=gnu
 CONFIGURE_ARGS+=--disable-cplusplus \
--disable-absolute-shared-libs \
@@ -42,6 +48,10 @@ do-build:
ulimit -s 12288 && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} ${ALL_TARGET}
 
+post-build:
+   sed -i 's/C_COMPILER=\"cc\"/C_COMPILER=\"egcc\"/' 
${WRKSRC}/bin/gambcomp-C.unix
+   sed -i 's/C_PREPROC=\"cc -E\"/C_PREPROC=\"egcc -E\"/' 
${WRKSRC}/bin/gambcomp-C.unix
+
 do-test:
cd ${WRKSRC}/tests && ${SETENV} ${TEST_ENV} ${MAKE_PROGRAM} \
${TEST_FLAGS} -f makefile ${TEST_TARGET}

Re: lang/gerbil build failures on i386

2019-08-05 Thread Christian Weisgerber 
On 2019-08-05, Jeremie Courreges-Anglas  wrote:

> Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> naddy, ajacoutot?

amd64.p uses the pbuild limits from the default login.conf.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: lang/gerbil build failures on i386

2019-08-05 Thread Timo Myyrä 



On Mon, Aug 5, 2019, at 20:23, Stuart Henderson wrote:
> On 2019/08/05 18:58, Jeremie Courreges-Anglas wrote:
> > On Mon, Aug 05 2019, Stuart Henderson  wrote:
> > > On 2019/08/05 17:25, Timo Myyrä wrote:
> > >> Juan Francisco Cantero Hurtado  writes:
> > 
> > [...]
> > 
> > >> > Could you test this patch?.
> > >> >
> > >> >
> > >> > diff --git Makefile Makefile
> > >> > index 88a777f7c30..7547cf59c6c 100644
> > >> > --- Makefile
> > >> > +++ Makefile
> > >> > @@ -39,7 +39,8 @@ NO_TEST =Yes
> > >> >  GERBIL_ROOT = ${PREFIX}/gerbil
> > >> >  
> > >> >  do-build:
> > >> > -  cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
> > >> > ./build.sh
> > >> > +  cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> > >> > +  ${SETENV} ${MAKE_ENV} ./build.sh
> > >> >  
> > >> >  do-install:
> > >> >${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> > >
> > > Trying that in my next build (though it would seem odd for it to require
> > > more stack on one machine than another?)
> 
> Unsurprisingly it didn't help.
> 
> > Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> > naddy, ajacoutot?
> 
> On i386 I did copy login.conf to the new machines.
> 
> Same results building lang/gerbil with ports-gcc.
> 
>

Gerbil uses lang/gambit to compile code so I think both would need to be 
compiled with gcc.

Though tags aren't strictly needed for the port and can be disabled.

Timo

Re: lang/gerbil build failures on i386

2019-08-05 Thread Stuart Henderson 
On 2019/08/05 18:58, Jeremie Courreges-Anglas wrote:
> On Mon, Aug 05 2019, Stuart Henderson  wrote:
> > On 2019/08/05 17:25, Timo Myyrä wrote:
> >> Juan Francisco Cantero Hurtado  writes:
> 
> [...]
> 
> >> > Could you test this patch?.
> >> >
> >> >
> >> > diff --git Makefile Makefile
> >> > index 88a777f7c30..7547cf59c6c 100644
> >> > --- Makefile
> >> > +++ Makefile
> >> > @@ -39,7 +39,8 @@ NO_TEST =  Yes
> >> >  GERBIL_ROOT =   ${PREFIX}/gerbil
> >> >  
> >> >  do-build:
> >> > -cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
> >> > ./build.sh
> >> > +cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> >> > +${SETENV} ${MAKE_ENV} ./build.sh
> >> >  
> >> >  do-install:
> >> >  ${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> >
> > Trying that in my next build (though it would seem odd for it to require
> > more stack on one machine than another?)

Unsurprisingly it didn't help.

> Or maybe amd64.p and exopi don't use the same limits (login.conf)?
> naddy, ajacoutot?

On i386 I did copy login.conf to the new machines.

Same results building lang/gerbil with ports-gcc.

Re: lang/gerbil build failures on i386

2019-08-05 Thread Timo Myyrä 
Juan Francisco Cantero Hurtado  writes:

> On Mon, Aug 05, 2019 at 04:04:37PM +0100, Stuart Henderson wrote:
>
>> On 2019/08/05 17:25, Timo Myyrä wrote:
>> > Juan Francisco Cantero Hurtado  writes:
>> > 
>> > > On Sun, Aug 04, 2019 at 09:15:58PM +0100, Stuart Henderson wrote:
>> > >
>> > >> On 2019/08/04 22:00, Antoine Jacoutot wrote:
>> > >> > I don't want to hijack this thread, but I just wanted to say that 
>> > >> > there are many
>> > >> > wolves hiding.
>> > >> > That gerbil port has *never* built successfully for me on exopi 
>> > >> > (amd64) since
>> > >> > its first import.
>> > >> 
>> > >> Thanks, glad it's not just me!
>> > >> 
>> > >> > 
>> > >> > cc -O2 -pipe -Wno-unused -Wno-write-strings
>> > >> > -Wdisabled-optimization -fwrapv -fno-strict-aliasing
>> > >> > -fno-math-errno -fomit-frame-pointer -fPIC -fno-common -rdynamic
>> > >> > -I"/usr/local/include/gambit" -o "gxpkg" gxpkg_.o gxpkg.o
>> > >> > "/usr/local/lib/gambit/libgambit.a" -lutil -lm
>> > >> > -L/usr/local/opt/openssl/lib -lssl -lcrypto
>> > >> > [*] Build gerbil tags
>> > >> > *** ERROR; build failed
>> > >> > 
>> > >> > And thank you gerbil for the useless output...
>> > >> 
>> > >> That is all I get from the default build, but if I run the "Build gerbil
>> > >> tags" part manually I get the extra bits I showed. (I don't know why it
>> > >> doesn't display this as part of a ports build though...it's running
>> > >> the same script!)
>> > >> 
>> > >> Perhaps there is something cpu dependent, I don't see any -march bits
>> > >> in gerbil/gambit, though there are some cpuid instructions used in asm 
>> > >> in
>> > >> gambit..basically 0 idea though.
>> > >> 
>> > >
>> > > That's part of the native backend and is not enabled by default.
>> > >
>> > > Could you test this patch?.
>> > >
>> > >
>> > > diff --git Makefile Makefile
>> > > index 88a777f7c30..7547cf59c6c 100644
>> > > --- Makefile
>> > > +++ Makefile
>> > > @@ -39,7 +39,8 @@ NO_TEST =  Yes
>> > >  GERBIL_ROOT =   ${PREFIX}/gerbil
>> > >  
>> > >  do-build:
>> > > -cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} 
>> > > ./build.sh
>> > > +cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
>> > > +${SETENV} ${MAKE_ENV} ./build.sh
>> > >  
>> > >  do-install:
>> > >  ${INSTALL_DATA_DIR} ${GERBIL_ROOT}
>> 
>> Trying that in my next build (though it would seem odd for it to require
>> more stack on one machine than another?)
>
> Yes, really odd. The next test would be to change the compiler to gcc. I
> would like to avoid that because gambit is really hard with the C
> compilers and a good test bed for the clang upgrades.
>
>> 
>> > Another diff try as well on problem machines to enable running std tests:
>> > 
>> > Index: Makefile
>> > ===
>> > RCS file: /cvs/ports/lang/gerbil/Makefile,v
>> > retrieving revision 1.7
>> > diff -u -p -u -p -r1.7 Makefile
>> > --- Makefile12 Jul 2019 20:47:18 -  1.7
>> > +++ Makefile5 Aug 2019 14:23:35 -
>> > @@ -34,8 +34,6 @@ MAKE_ENV +=   CPPFLAGS=-I${LOCALBASE}/incl
>> > GERBIL_PATH=${WRKINST}${PREFIX}/gerbil \
>> > GAMBCOMP_VERBOSE=1
>> >  
>> > -NO_TEST =  Yes
>> > -
>> >  GERBIL_ROOT =  ${PREFIX}/gerbil
>> >  
>> >  do-build:
>> > @@ -48,5 +46,8 @@ do-install:
>> > ${INSTALL_DATA} ${WRKSRC}/etc/gerbil.el 
>> > ${PREFIX}/share/emacs/site-lisp
>> > ${INSTALL_DATA} ${WRKSRC}/*.md ${GERBIL_ROOT}
>> > ${INSTALL_DATA} ${WRKSRC}/*.txt ${GERBIL_ROOT}
>> > +
>> > +do-test:
>> > +   ${SETENV} ${MAKE_ENV} ${WRKSRC}/bin/gxi 
>> > ${WRKSRC}/src/std/run-tests.ss
>> >  
>> >  .include 
>> 
>> Seems useful to have anyone, but do-test depends on build, so it won't be
>> runnable on this machine.
>
> Timo, I can commit the patch if you want. We usually like to have the
> tests enabled where possible.

Yeah, that can be committed in any case.

Timo

Re: lang/gerbil build failures on i386

2019-08-05 Thread Jeremie Courreges-Anglas 
On Mon, Aug 05 2019, Stuart Henderson  wrote:
> On 2019/08/05 17:25, Timo Myyrä wrote:
>> Juan Francisco Cantero Hurtado  writes:

[...]

>> > Could you test this patch?.
>> >
>> >
>> > diff --git Makefile Makefile
>> > index 88a777f7c30..7547cf59c6c 100644
>> > --- Makefile
>> > +++ Makefile
>> > @@ -39,7 +39,8 @@ NO_TEST =Yes
>> >  GERBIL_ROOT = ${PREFIX}/gerbil
>> >  
>> >  do-build:
>> > -  cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} ./build.sh
>> > +  cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
>> > +  ${SETENV} ${MAKE_ENV} ./build.sh
>> >  
>> >  do-install:
>> >${INSTALL_DATA_DIR} ${GERBIL_ROOT}
>
> Trying that in my next build (though it would seem odd for it to require
> more stack on one machine than another?)

Or maybe amd64.p and exopi don't use the same limits (login.conf)?
naddy, ajacoutot?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: lang/gerbil build failures on i386

2019-08-05 Thread Juan Francisco Cantero Hurtado 
On Mon, Aug 05, 2019 at 04:04:37PM +0100, Stuart Henderson wrote:
> On 2019/08/05 17:25, Timo Myyrä wrote:
> > Juan Francisco Cantero Hurtado  writes:
> > 
> > > On Sun, Aug 04, 2019 at 09:15:58PM +0100, Stuart Henderson wrote:
> > >
> > >> On 2019/08/04 22:00, Antoine Jacoutot wrote:
> > >> > I don't want to hijack this thread, but I just wanted to say that 
> > >> > there are many
> > >> > wolves hiding.
> > >> > That gerbil port has *never* built successfully for me on exopi 
> > >> > (amd64) since
> > >> > its first import.
> > >> 
> > >> Thanks, glad it's not just me!
> > >> 
> > >> > 
> > >> > cc -O2 -pipe -Wno-unused -Wno-write-strings
> > >> > -Wdisabled-optimization -fwrapv -fno-strict-aliasing
> > >> > -fno-math-errno -fomit-frame-pointer -fPIC -fno-common -rdynamic
> > >> > -I"/usr/local/include/gambit" -o "gxpkg" gxpkg_.o gxpkg.o
> > >> > "/usr/local/lib/gambit/libgambit.a" -lutil -lm
> > >> > -L/usr/local/opt/openssl/lib -lssl -lcrypto
> > >> > [*] Build gerbil tags
> > >> > *** ERROR; build failed
> > >> > 
> > >> > And thank you gerbil for the useless output...
> > >> 
> > >> That is all I get from the default build, but if I run the "Build gerbil
> > >> tags" part manually I get the extra bits I showed. (I don't know why it
> > >> doesn't display this as part of a ports build though...it's running
> > >> the same script!)
> > >> 
> > >> Perhaps there is something cpu dependent, I don't see any -march bits
> > >> in gerbil/gambit, though there are some cpuid instructions used in asm in
> > >> gambit..basically 0 idea though.
> > >> 
> > >
> > > That's part of the native backend and is not enabled by default.
> > >
> > > Could you test this patch?.
> > >
> > >
> > > diff --git Makefile Makefile
> > > index 88a777f7c30..7547cf59c6c 100644
> > > --- Makefile
> > > +++ Makefile
> > > @@ -39,7 +39,8 @@ NO_TEST =   Yes
> > >  GERBIL_ROOT =${PREFIX}/gerbil
> > >  
> > >  do-build:
> > > - cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} ./build.sh
> > > + cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> > > + ${SETENV} ${MAKE_ENV} ./build.sh
> > >  
> > >  do-install:
> > >   ${INSTALL_DATA_DIR} ${GERBIL_ROOT}
> 
> Trying that in my next build (though it would seem odd for it to require
> more stack on one machine than another?)

Yes, really odd. The next test would be to change the compiler to gcc. I
would like to avoid that because gambit is really hard with the C
compilers and a good test bed for the clang upgrades.

> 
> > Another diff try as well on problem machines to enable running std tests:
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/lang/gerbil/Makefile,v
> > retrieving revision 1.7
> > diff -u -p -u -p -r1.7 Makefile
> > --- Makefile12 Jul 2019 20:47:18 -  1.7
> > +++ Makefile5 Aug 2019 14:23:35 -
> > @@ -34,8 +34,6 @@ MAKE_ENV +=   CPPFLAGS=-I${LOCALBASE}/incl
> > GERBIL_PATH=${WRKINST}${PREFIX}/gerbil \
> > GAMBCOMP_VERBOSE=1
> >  
> > -NO_TEST =  Yes
> > -
> >  GERBIL_ROOT =  ${PREFIX}/gerbil
> >  
> >  do-build:
> > @@ -48,5 +46,8 @@ do-install:
> > ${INSTALL_DATA} ${WRKSRC}/etc/gerbil.el 
> > ${PREFIX}/share/emacs/site-lisp
> > ${INSTALL_DATA} ${WRKSRC}/*.md ${GERBIL_ROOT}
> > ${INSTALL_DATA} ${WRKSRC}/*.txt ${GERBIL_ROOT}
> > +
> > +do-test:
> > +   ${SETENV} ${MAKE_ENV} ${WRKSRC}/bin/gxi 
> > ${WRKSRC}/src/std/run-tests.ss
> >  
> >  .include 
> 
> Seems useful to have anyone, but do-test depends on build, so it won't be
> runnable on this machine.

Timo, I can commit the patch if you want. We usually like to have the
tests enabled where possible.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: lang/gerbil build failures on i386

2019-08-05 Thread Stuart Henderson 
On 2019/08/05 17:25, Timo Myyrä wrote:
> Juan Francisco Cantero Hurtado  writes:
> 
> > On Sun, Aug 04, 2019 at 09:15:58PM +0100, Stuart Henderson wrote:
> >
> >> On 2019/08/04 22:00, Antoine Jacoutot wrote:
> >> > I don't want to hijack this thread, but I just wanted to say that there 
> >> > are many
> >> > wolves hiding.
> >> > That gerbil port has *never* built successfully for me on exopi (amd64) 
> >> > since
> >> > its first import.
> >> 
> >> Thanks, glad it's not just me!
> >> 
> >> > 
> >> > cc -O2 -pipe -Wno-unused -Wno-write-strings
> >> > -Wdisabled-optimization -fwrapv -fno-strict-aliasing
> >> > -fno-math-errno -fomit-frame-pointer -fPIC -fno-common -rdynamic
> >> > -I"/usr/local/include/gambit" -o "gxpkg" gxpkg_.o gxpkg.o
> >> > "/usr/local/lib/gambit/libgambit.a" -lutil -lm
> >> > -L/usr/local/opt/openssl/lib -lssl -lcrypto
> >> > [*] Build gerbil tags
> >> > *** ERROR; build failed
> >> > 
> >> > And thank you gerbil for the useless output...
> >> 
> >> That is all I get from the default build, but if I run the "Build gerbil
> >> tags" part manually I get the extra bits I showed. (I don't know why it
> >> doesn't display this as part of a ports build though...it's running
> >> the same script!)
> >> 
> >> Perhaps there is something cpu dependent, I don't see any -march bits
> >> in gerbil/gambit, though there are some cpuid instructions used in asm in
> >> gambit..basically 0 idea though.
> >> 
> >
> > That's part of the native backend and is not enabled by default.
> >
> > Could you test this patch?.
> >
> >
> > diff --git Makefile Makefile
> > index 88a777f7c30..7547cf59c6c 100644
> > --- Makefile
> > +++ Makefile
> > @@ -39,7 +39,8 @@ NO_TEST = Yes
> >  GERBIL_ROOT =  ${PREFIX}/gerbil
> >  
> >  do-build:
> > -   cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} ./build.sh
> > +   cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> > +   ${SETENV} ${MAKE_ENV} ./build.sh
> >  
> >  do-install:
> > ${INSTALL_DATA_DIR} ${GERBIL_ROOT}

Trying that in my next build (though it would seem odd for it to require
more stack on one machine than another?)

> Another diff try as well on problem machines to enable running std tests:
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/gerbil/Makefile,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 Makefile
> --- Makefile12 Jul 2019 20:47:18 -  1.7
> +++ Makefile5 Aug 2019 14:23:35 -
> @@ -34,8 +34,6 @@ MAKE_ENV +=   CPPFLAGS=-I${LOCALBASE}/incl
> GERBIL_PATH=${WRKINST}${PREFIX}/gerbil \
> GAMBCOMP_VERBOSE=1
>  
> -NO_TEST =  Yes
> -
>  GERBIL_ROOT =  ${PREFIX}/gerbil
>  
>  do-build:
> @@ -48,5 +46,8 @@ do-install:
> ${INSTALL_DATA} ${WRKSRC}/etc/gerbil.el 
> ${PREFIX}/share/emacs/site-lisp
> ${INSTALL_DATA} ${WRKSRC}/*.md ${GERBIL_ROOT}
> ${INSTALL_DATA} ${WRKSRC}/*.txt ${GERBIL_ROOT}
> +
> +do-test:
> +   ${SETENV} ${MAKE_ENV} ${WRKSRC}/bin/gxi ${WRKSRC}/src/std/run-tests.ss
>  
>  .include 

Seems useful to have anyone, but do-test depends on build, so it won't be
runnable on this machine.

Re: lang/gerbil build failures on i386

2019-08-05 Thread Timo Myyrä 
Juan Francisco Cantero Hurtado  writes:

> On Sun, Aug 04, 2019 at 09:15:58PM +0100, Stuart Henderson wrote:
>
>> On 2019/08/04 22:00, Antoine Jacoutot wrote:
>> > I don't want to hijack this thread, but I just wanted to say that there 
>> > are many
>> > wolves hiding.
>> > That gerbil port has *never* built successfully for me on exopi (amd64) 
>> > since
>> > its first import.
>> 
>> Thanks, glad it's not just me!
>> 
>> > 
>> > cc -O2 -pipe -Wno-unused -Wno-write-strings
>> > -Wdisabled-optimization -fwrapv -fno-strict-aliasing
>> > -fno-math-errno -fomit-frame-pointer -fPIC -fno-common -rdynamic
>> > -I"/usr/local/include/gambit" -o "gxpkg" gxpkg_.o gxpkg.o
>> > "/usr/local/lib/gambit/libgambit.a" -lutil -lm
>> > -L/usr/local/opt/openssl/lib -lssl -lcrypto
>> > [*] Build gerbil tags
>> > *** ERROR; build failed
>> > 
>> > And thank you gerbil for the useless output...
>> 
>> That is all I get from the default build, but if I run the "Build gerbil
>> tags" part manually I get the extra bits I showed. (I don't know why it
>> doesn't display this as part of a ports build though...it's running
>> the same script!)
>> 
>> Perhaps there is something cpu dependent, I don't see any -march bits
>> in gerbil/gambit, though there are some cpuid instructions used in asm in
>> gambit..basically 0 idea though.
>> 
>
> That's part of the native backend and is not enabled by default.
>
> Could you test this patch?.
>
>
> diff --git Makefile Makefile
> index 88a777f7c30..7547cf59c6c 100644
> --- Makefile
> +++ Makefile
> @@ -39,7 +39,8 @@ NO_TEST =   Yes
>  GERBIL_ROOT =${PREFIX}/gerbil
>  
>  do-build:
> - cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} ./build.sh
> + cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
> + ${SETENV} ${MAKE_ENV} ./build.sh
>  
>  do-install:
>   ${INSTALL_DATA_DIR} ${GERBIL_ROOT}

Another diff try as well on problem machines to enable running std tests:

Index: Makefile
===
RCS file: /cvs/ports/lang/gerbil/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:47:18 -  1.7
+++ Makefile5 Aug 2019 14:23:35 -
@@ -34,8 +34,6 @@ MAKE_ENV +=   CPPFLAGS=-I${LOCALBASE}/incl
GERBIL_PATH=${WRKINST}${PREFIX}/gerbil \
GAMBCOMP_VERBOSE=1
 
-NO_TEST =  Yes
-
 GERBIL_ROOT =  ${PREFIX}/gerbil
 
 do-build:
@@ -48,5 +46,8 @@ do-install:
${INSTALL_DATA} ${WRKSRC}/etc/gerbil.el ${PREFIX}/share/emacs/site-lisp
${INSTALL_DATA} ${WRKSRC}/*.md ${GERBIL_ROOT}
${INSTALL_DATA} ${WRKSRC}/*.txt ${GERBIL_ROOT}
+
+do-test:
+   ${SETENV} ${MAKE_ENV} ${WRKSRC}/bin/gxi ${WRKSRC}/src/std/run-tests.ss
 
 .include

Re: lang/gerbil build failures on i386

2019-08-04 Thread Juan Francisco Cantero Hurtado 
On Sun, Aug 04, 2019 at 09:15:58PM +0100, Stuart Henderson wrote:
> On 2019/08/04 22:00, Antoine Jacoutot wrote:
> > I don't want to hijack this thread, but I just wanted to say that there are 
> > many
> > wolves hiding.
> > That gerbil port has *never* built successfully for me on exopi (amd64) 
> > since
> > its first import.
> 
> Thanks, glad it's not just me!
> 
> > 
> > cc  -O2 -pipe -Wno-unused -Wno-write-strings -Wdisabled-optimization 
> > -fwrapv -fno-strict-aliasing -fno-math-errno -fomit-frame-pointer -fPIC 
> > -fno-common   -rdynamic   -I"/usr/local/include/gambit"  -o "gxpkg"   
> > gxpkg_.o gxpkg.o "/usr/local/lib/gambit/libgambit.a" -lutil -lm  
> > -L/usr/local/opt/openssl/lib -lssl -lcrypto 
> > [*] Build gerbil tags
> > *** ERROR; build failed
> > 
> > And thank you gerbil for the useless output...
> 
> That is all I get from the default build, but if I run the "Build gerbil
> tags" part manually I get the extra bits I showed. (I don't know why it
> doesn't display this as part of a ports build though...it's running
> the same script!)
> 
> Perhaps there is something cpu dependent, I don't see any -march bits
> in gerbil/gambit, though there are some cpuid instructions used in asm in
> gambit..basically 0 idea though.
> 

That's part of the native backend and is not enabled by default.

Could you test this patch?.


diff --git Makefile Makefile
index 88a777f7c30..7547cf59c6c 100644
--- Makefile
+++ Makefile
@@ -39,7 +39,8 @@ NO_TEST = Yes
 GERBIL_ROOT =  ${PREFIX}/gerbil
 
 do-build:
-   cd ${WRKSRC}/src && ulimit -n 1024 && ${SETENV} ${MAKE_ENV} ./build.sh
+   cd ${WRKSRC}/src && ulimit -n 1024 -s 16384 && \
+   ${SETENV} ${MAKE_ENV} ./build.sh
 
 do-install:
${INSTALL_DATA_DIR} ${GERBIL_ROOT}

Re: lang/gerbil build failures on i386

2019-08-04 Thread Christian Weisgerber 
On 2019-08-04, Antoine Jacoutot  wrote:

> That gerbil port has *never* built successfully for me on exopi (amd64) since
> its first import.

By contrast, it builds fine on amd64*.ports.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: lang/gerbil build failures on i386

2019-08-04 Thread Stuart Henderson 
On 2019/08/04 22:00, Antoine Jacoutot wrote:
> I don't want to hijack this thread, but I just wanted to say that there are 
> many
> wolves hiding.
> That gerbil port has *never* built successfully for me on exopi (amd64) since
> its first import.

Thanks, glad it's not just me!

> 
> cc  -O2 -pipe -Wno-unused -Wno-write-strings -Wdisabled-optimization 
> -fwrapv -fno-strict-aliasing -fno-math-errno -fomit-frame-pointer -fPIC 
> -fno-common   -rdynamic   -I"/usr/local/include/gambit"  -o "gxpkg"   
> gxpkg_.o gxpkg.o "/usr/local/lib/gambit/libgambit.a" -lutil -lm  
> -L/usr/local/opt/openssl/lib -lssl -lcrypto 
> [*] Build gerbil tags
> *** ERROR; build failed
> 
> And thank you gerbil for the useless output...

That is all I get from the default build, but if I run the "Build gerbil
tags" part manually I get the extra bits I showed. (I don't know why it
doesn't display this as part of a ports build though...it's running
the same script!)

Perhaps there is something cpu dependent, I don't see any -march bits
in gerbil/gambit, though there are some cpuid instructions used in asm in
gambit..basically 0 idea though.

Re: lang/gerbil build failures on i386

2019-08-04 Thread Antoine Jacoutot 
On Sun, Aug 04, 2019 at 08:10:27PM +0100, Stuart Henderson wrote:
> On 2019/08/04 21:55, Timo Myyrä wrote:
> > Stuart Henderson  writes:
> > 
> > > On 2019/08/04 08:34, Timo Myyrä wrote:
> > >
> > >> Stuart Henderson  writes:
> > >> 
> > >> > On 2019/08/03 14:36, Timo Myyrä wrote:
> > >> >
> > >> >> Stuart Henderson  writes:
> > >> >> 
> > >> >> > I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any 
> > >> >> > ideas?
> > >> >> >
> > >> >> > $ [...] ./build.sh tags 
> > >> >> >  <
> > >> >> > [*] Build gerbil tags
> > >> >> > TAG gerbil/compiler/base.ss
> > >> >> > TAG gerbil/compiler/compile.ss
> > >> >> > TAG gerbil/compiler/driver.ss
> > >> >> > TAG gerbil/compiler/optimize-ann.ss
> > >> >> > TAG gerbil/compiler/optimize-base.ss
> > >> >> > TAG gerbil/compiler/optimize-call.ss
> > >> >> > TAG gerbil/compiler/optimize-top.ss
> > >> >> > TAG gerbil/compiler/optimize-xform.ss
> > >> >> > TAG gerbil/compiler/optimize.ss
> > >> >> > TAG gerbil/compiler/ssxi.ss
> > >> >> > TAG gerbil/compiler.ss
> > >> >> > *** ERROR -- (Argument 2) Out of range
> > >> >> > (vector-ref
> > >> >> >  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil 
> > >> >> > -> gambc compiler" "package: gerbil" "namespace:...
> > >> >> >  28)
> > >> >> > *** ERROR; build failed
> > >> >> >
> > >> >> >
> > >> >> > I'm building on new hardware, but other ports are all building ok.
> > >> >> >
> > >> >> > This is repeatable (either rerunning ./build.sh tags or making a 
> > >> >> > whole clean
> > >> >> > build from ports).
> > >> >> >
> > >> >> > Any ideas?
> > >> >> 
> > >> >> I just tested Gerbil port on new i386 vm host and it did build 
> > >> >> successfully.
> > >> >> I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
> > >> >> /usr/ports/lang/gerbil && make".
> > >> >> 
> > >> >> Did you use proot / dbp or anything else which could affect the build 
> > >> >> result?
> > >> >> 
> > >> >> timo
> > >> >> 
> > >> >
> > >> > My build setup on this machine is similar to the ones I was previously
> > >> > using which worked ok (slight differences in paths but that shouldn't 
> > >> > affect
> > >> > anything in a ports build). No proot, I normally use dpb, but get the 
> > >> > same
> > >> > results with a manual "make".
> > >> >
> > >> > Looks similar to (same as?) this problem which aja@ ran into, but I 
> > >> > don't
> > >> > know what happened with that ..
> > >> > https://marc.info/?l=openbsd-ports-cvs&m=154340876315118&w=2
> > >> 
> > >> I don't remember if there was any solution to that.
> > >> As Gerbil uses Gambit scheme as a backend, could the compilation flags 
> > >> of that
> > >> affect the Gerbil build?
> > >> Did you build the Gambit package yourself or did you use package?
> > >
> > > This is on the machine that builds snapshot packages. So I suppose
> > > the answer is 'both' :-)
> > >
> > > It is a clean build with no non-default flags that would affect 
> > > compilation.
> > >
> > >> Reading Gambit's INSTALL.txt:
> > >>   "Note that some C compilers generate incorrect code when
> > >>   compiling Gambit with --enable-c-opt, notably GCC 4.6.0 .  So the
> > >>   --enable-c-opt option should be used with great care."
> > >> 
> > >> Most of the Gambit documentation seems to recommend to use GCC when 
> > >> compiling
> > >> it so I don't know if LLVM gives some issue with it.
> > >> 
> > >> Could you test what your gxi is gives when executing:
> > >> $ cat < /tmp/test.ss   
> > >>  
> > >> > (import :std/misc/ports)
> > >> > (for-each (lambda (l)
> > >> >  (display l) (newline))
> > >> > (read-file-lines 
> > >> > "/usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> > >> > EOF
> > >> 
> > >> /usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi /tmp/test.ss
> > >> 
> > >> Timo
> > >> 
> > >> 
> > >
> > > sthen@i386-2[/tmp] cat test.ss
> > > (import :std/misc/ports)
> > > (for-each (lambda (l)
> > >  (display l) (newline))
> > > (read-file-lines 
> > > "/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> > > sthen@i386-2[/tmp] /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi test.ss
> > > ;;; -*- Gerbil -*-
> > > ;;; (C) vyzo at hackzen.org
> > > ;;; gerbil -> gambc compiler
> > > package: gerbil
> > > namespace: gxc
> > >
> > > (import :gerbil/compiler/driver)
> > > (export (import: :gerbil/compiler/driver))
> > 
> > Seems ok that one, what does running the gxtags manually give:
> > /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxtags  -o /tmp/TEST-TAG
> > /pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss
> > 
> > if the problem is limited into gxtags for some reason?
> > 
> > timo
> > 
> 
> $ doas -u _pbuild /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxtags  -o 
> /tmp/TEST-TAG  /pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss 
> *** ERROR IN _gx#load-runtime! -- Cannot determine GERBIL_HOME
>

Re: lang/gerbil build failures on i386

2019-08-04 Thread Stuart Henderson 
On 2019/08/04 21:55, Timo Myyrä wrote:
> Stuart Henderson  writes:
> 
> > On 2019/08/04 08:34, Timo Myyrä wrote:
> >
> >> Stuart Henderson  writes:
> >> 
> >> > On 2019/08/03 14:36, Timo Myyrä wrote:
> >> >
> >> >> Stuart Henderson  writes:
> >> >> 
> >> >> > I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any 
> >> >> > ideas?
> >> >> >
> >> >> > $ [...] ./build.sh tags   
> >> >> ><
> >> >> > [*] Build gerbil tags
> >> >> > TAG gerbil/compiler/base.ss
> >> >> > TAG gerbil/compiler/compile.ss
> >> >> > TAG gerbil/compiler/driver.ss
> >> >> > TAG gerbil/compiler/optimize-ann.ss
> >> >> > TAG gerbil/compiler/optimize-base.ss
> >> >> > TAG gerbil/compiler/optimize-call.ss
> >> >> > TAG gerbil/compiler/optimize-top.ss
> >> >> > TAG gerbil/compiler/optimize-xform.ss
> >> >> > TAG gerbil/compiler/optimize.ss
> >> >> > TAG gerbil/compiler/ssxi.ss
> >> >> > TAG gerbil/compiler.ss
> >> >> > *** ERROR -- (Argument 2) Out of range
> >> >> > (vector-ref
> >> >> >  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> 
> >> >> > gambc compiler" "package: gerbil" "namespace:...
> >> >> >  28)
> >> >> > *** ERROR; build failed
> >> >> >
> >> >> >
> >> >> > I'm building on new hardware, but other ports are all building ok.
> >> >> >
> >> >> > This is repeatable (either rerunning ./build.sh tags or making a 
> >> >> > whole clean
> >> >> > build from ports).
> >> >> >
> >> >> > Any ideas?
> >> >> 
> >> >> I just tested Gerbil port on new i386 vm host and it did build 
> >> >> successfully.
> >> >> I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
> >> >> /usr/ports/lang/gerbil && make".
> >> >> 
> >> >> Did you use proot / dbp or anything else which could affect the build 
> >> >> result?
> >> >> 
> >> >> timo
> >> >> 
> >> >
> >> > My build setup on this machine is similar to the ones I was previously
> >> > using which worked ok (slight differences in paths but that shouldn't 
> >> > affect
> >> > anything in a ports build). No proot, I normally use dpb, but get the 
> >> > same
> >> > results with a manual "make".
> >> >
> >> > Looks similar to (same as?) this problem which aja@ ran into, but I don't
> >> > know what happened with that ..
> >> > https://marc.info/?l=openbsd-ports-cvs&m=154340876315118&w=2
> >> 
> >> I don't remember if there was any solution to that.
> >> As Gerbil uses Gambit scheme as a backend, could the compilation flags of 
> >> that
> >> affect the Gerbil build?
> >> Did you build the Gambit package yourself or did you use package?
> >
> > This is on the machine that builds snapshot packages. So I suppose
> > the answer is 'both' :-)
> >
> > It is a clean build with no non-default flags that would affect compilation.
> >
> >> Reading Gambit's INSTALL.txt:
> >>   "Note that some C compilers generate incorrect code when
> >>   compiling Gambit with --enable-c-opt, notably GCC 4.6.0 .  So the
> >>   --enable-c-opt option should be used with great care."
> >> 
> >> Most of the Gambit documentation seems to recommend to use GCC when 
> >> compiling
> >> it so I don't know if LLVM gives some issue with it.
> >> 
> >> Could you test what your gxi is gives when executing:
> >> $ cat < /tmp/test.ss 
> >>
> >> > (import :std/misc/ports)
> >> > (for-each (lambda (l)
> >> >  (display l) (newline))
> >> > (read-file-lines 
> >> > "/usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> >> > EOF
> >> 
> >> /usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi /tmp/test.ss
> >> 
> >> Timo
> >> 
> >> 
> >
> > sthen@i386-2[/tmp] cat test.ss
> > (import :std/misc/ports)
> > (for-each (lambda (l)
> >  (display l) (newline))
> > (read-file-lines 
> > "/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> > sthen@i386-2[/tmp] /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi test.ss
> > ;;; -*- Gerbil -*-
> > ;;; (C) vyzo at hackzen.org
> > ;;; gerbil -> gambc compiler
> > package: gerbil
> > namespace: gxc
> >
> > (import :gerbil/compiler/driver)
> > (export (import: :gerbil/compiler/driver))
> 
> Seems ok that one, what does running the gxtags manually give:
> /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxtags  -o /tmp/TEST-TAG
> /pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss
> 
> if the problem is limited into gxtags for some reason?
> 
> timo
> 

$ doas -u _pbuild /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxtags  -o 
/tmp/TEST-TAG  /pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss 
*** ERROR IN _gx#load-runtime! -- Cannot determine GERBIL_HOME

$ doas -u _pbuild env GERBIL_HOME=/pobj/gerbil-0.15.1/gerbil-0.15.1  
/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxtags  -o /tmp/TEST-TAG  
/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss
TAG /pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss
*** ERROR -- (Argument 2) Out of range
(vector-ref #(";;; -*- Gerbil -*-" ";;; (C) vyzo at

Re: lang/gerbil build failures on i386

2019-08-04 Thread Timo Myyrä 
Stuart Henderson  writes:

> On 2019/08/04 08:34, Timo Myyrä wrote:
>
>> Stuart Henderson  writes:
>> 
>> > On 2019/08/03 14:36, Timo Myyrä wrote:
>> >
>> >> Stuart Henderson  writes:
>> >> 
>> >> > I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any 
>> >> > ideas?
>> >> >
>> >> > $ [...] ./build.sh tags 
>> >> >  <
>> >> > [*] Build gerbil tags
>> >> > TAG gerbil/compiler/base.ss
>> >> > TAG gerbil/compiler/compile.ss
>> >> > TAG gerbil/compiler/driver.ss
>> >> > TAG gerbil/compiler/optimize-ann.ss
>> >> > TAG gerbil/compiler/optimize-base.ss
>> >> > TAG gerbil/compiler/optimize-call.ss
>> >> > TAG gerbil/compiler/optimize-top.ss
>> >> > TAG gerbil/compiler/optimize-xform.ss
>> >> > TAG gerbil/compiler/optimize.ss
>> >> > TAG gerbil/compiler/ssxi.ss
>> >> > TAG gerbil/compiler.ss
>> >> > *** ERROR -- (Argument 2) Out of range
>> >> > (vector-ref
>> >> >  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> 
>> >> > gambc compiler" "package: gerbil" "namespace:...
>> >> >  28)
>> >> > *** ERROR; build failed
>> >> >
>> >> >
>> >> > I'm building on new hardware, but other ports are all building ok.
>> >> >
>> >> > This is repeatable (either rerunning ./build.sh tags or making a whole 
>> >> > clean
>> >> > build from ports).
>> >> >
>> >> > Any ideas?
>> >> 
>> >> I just tested Gerbil port on new i386 vm host and it did build 
>> >> successfully.
>> >> I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
>> >> /usr/ports/lang/gerbil && make".
>> >> 
>> >> Did you use proot / dbp or anything else which could affect the build 
>> >> result?
>> >> 
>> >> timo
>> >> 
>> >
>> > My build setup on this machine is similar to the ones I was previously
>> > using which worked ok (slight differences in paths but that shouldn't 
>> > affect
>> > anything in a ports build). No proot, I normally use dpb, but get the same
>> > results with a manual "make".
>> >
>> > Looks similar to (same as?) this problem which aja@ ran into, but I don't
>> > know what happened with that ..
>> > https://marc.info/?l=openbsd-ports-cvs&m=154340876315118&w=2
>> 
>> I don't remember if there was any solution to that.
>> As Gerbil uses Gambit scheme as a backend, could the compilation flags of 
>> that
>> affect the Gerbil build?
>> Did you build the Gambit package yourself or did you use package?
>
> This is on the machine that builds snapshot packages. So I suppose
> the answer is 'both' :-)
>
> It is a clean build with no non-default flags that would affect compilation.
>
>> Reading Gambit's INSTALL.txt:
>>   "Note that some C compilers generate incorrect code when
>>   compiling Gambit with --enable-c-opt, notably GCC 4.6.0 .  So the
>>   --enable-c-opt option should be used with great care."
>> 
>> Most of the Gambit documentation seems to recommend to use GCC when compiling
>> it so I don't know if LLVM gives some issue with it.
>> 
>> Could you test what your gxi is gives when executing:
>> $ cat < /tmp/test.ss   
>>  
>> > (import :std/misc/ports)
>> > (for-each (lambda (l)
>> >  (display l) (newline))
>> > (read-file-lines 
>> > "/usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
>> > EOF
>> 
>> /usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi /tmp/test.ss
>> 
>> Timo
>> 
>> 
>
> sthen@i386-2[/tmp] cat test.ss
> (import :std/misc/ports)
> (for-each (lambda (l)
>  (display l) (newline))
> (read-file-lines 
> "/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> sthen@i386-2[/tmp] /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi test.ss
> ;;; -*- Gerbil -*-
> ;;; (C) vyzo at hackzen.org
> ;;; gerbil -> gambc compiler
> package: gerbil
> namespace: gxc
>
> (import :gerbil/compiler/driver)
> (export (import: :gerbil/compiler/driver))

Seems ok that one, what does running the gxtags manually give:
/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxtags  -o /tmp/TEST-TAG
/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss

if the problem is limited into gxtags for some reason?

timo

Re: lang/gerbil build failures on i386

2019-08-04 Thread Stuart Henderson 
On 2019/08/04 08:34, Timo Myyrä wrote:
> Stuart Henderson  writes:
> 
> > On 2019/08/03 14:36, Timo Myyrä wrote:
> >
> >> Stuart Henderson  writes:
> >> 
> >> > I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any 
> >> > ideas?
> >> >
> >> > $ [...] ./build.sh tags  
> >> > <
> >> > [*] Build gerbil tags
> >> > TAG gerbil/compiler/base.ss
> >> > TAG gerbil/compiler/compile.ss
> >> > TAG gerbil/compiler/driver.ss
> >> > TAG gerbil/compiler/optimize-ann.ss
> >> > TAG gerbil/compiler/optimize-base.ss
> >> > TAG gerbil/compiler/optimize-call.ss
> >> > TAG gerbil/compiler/optimize-top.ss
> >> > TAG gerbil/compiler/optimize-xform.ss
> >> > TAG gerbil/compiler/optimize.ss
> >> > TAG gerbil/compiler/ssxi.ss
> >> > TAG gerbil/compiler.ss
> >> > *** ERROR -- (Argument 2) Out of range
> >> > (vector-ref
> >> >  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> 
> >> > gambc compiler" "package: gerbil" "namespace:...
> >> >  28)
> >> > *** ERROR; build failed
> >> >
> >> >
> >> > I'm building on new hardware, but other ports are all building ok.
> >> >
> >> > This is repeatable (either rerunning ./build.sh tags or making a whole 
> >> > clean
> >> > build from ports).
> >> >
> >> > Any ideas?
> >> 
> >> I just tested Gerbil port on new i386 vm host and it did build 
> >> successfully.
> >> I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
> >> /usr/ports/lang/gerbil && make".
> >> 
> >> Did you use proot / dbp or anything else which could affect the build 
> >> result?
> >> 
> >> timo
> >> 
> >
> > My build setup on this machine is similar to the ones I was previously
> > using which worked ok (slight differences in paths but that shouldn't affect
> > anything in a ports build). No proot, I normally use dpb, but get the same
> > results with a manual "make".
> >
> > Looks similar to (same as?) this problem which aja@ ran into, but I don't
> > know what happened with that ..
> > https://marc.info/?l=openbsd-ports-cvs&m=154340876315118&w=2
> 
> I don't remember if there was any solution to that.
> As Gerbil uses Gambit scheme as a backend, could the compilation flags of that
> affect the Gerbil build?
> Did you build the Gambit package yourself or did you use package?

This is on the machine that builds snapshot packages. So I suppose
the answer is 'both' :-)

It is a clean build with no non-default flags that would affect compilation.

> Reading Gambit's INSTALL.txt:
>   "Note that some C compilers generate incorrect code when
>   compiling Gambit with --enable-c-opt, notably GCC 4.6.0 .  So the
>   --enable-c-opt option should be used with great care."
> 
> Most of the Gambit documentation seems to recommend to use GCC when compiling
> it so I don't know if LLVM gives some issue with it.
> 
> Could you test what your gxi is gives when executing:
> $ cat < /tmp/test.ss
> 
> > (import :std/misc/ports)
> > (for-each (lambda (l)
> >  (display l) (newline))
> > (read-file-lines 
> > "/usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> > EOF
> 
> /usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi /tmp/test.ss
> 
> Timo
> 
> 

sthen@i386-2[/tmp] cat test.ss
(import :std/misc/ports)
(for-each (lambda (l)
 (display l) (newline))
(read-file-lines 
"/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
sthen@i386-2[/tmp] /pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi test.ss
;;; -*- Gerbil -*-
;;; (C) vyzo at hackzen.org
;;; gerbil -> gambc compiler
package: gerbil
namespace: gxc

(import :gerbil/compiler/driver)
(export (import: :gerbil/compiler/driver))

Re: lang/gerbil build failures on i386

2019-08-03 Thread Timo Myyrä 
Stuart Henderson  writes:

> On 2019/08/03 14:36, Timo Myyrä wrote:
>
>> Stuart Henderson  writes:
>> 
>> > I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any ideas?
>> >
>> > $ [...] ./build.sh tags
>> >   <
>> > [*] Build gerbil tags
>> > TAG gerbil/compiler/base.ss
>> > TAG gerbil/compiler/compile.ss
>> > TAG gerbil/compiler/driver.ss
>> > TAG gerbil/compiler/optimize-ann.ss
>> > TAG gerbil/compiler/optimize-base.ss
>> > TAG gerbil/compiler/optimize-call.ss
>> > TAG gerbil/compiler/optimize-top.ss
>> > TAG gerbil/compiler/optimize-xform.ss
>> > TAG gerbil/compiler/optimize.ss
>> > TAG gerbil/compiler/ssxi.ss
>> > TAG gerbil/compiler.ss
>> > *** ERROR -- (Argument 2) Out of range
>> > (vector-ref
>> >  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> gambc 
>> > compiler" "package: gerbil" "namespace:...
>> >  28)
>> > *** ERROR; build failed
>> >
>> >
>> > I'm building on new hardware, but other ports are all building ok.
>> >
>> > This is repeatable (either rerunning ./build.sh tags or making a whole 
>> > clean
>> > build from ports).
>> >
>> > Any ideas?
>> 
>> I just tested Gerbil port on new i386 vm host and it did build successfully.
>> I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
>> /usr/ports/lang/gerbil && make".
>> 
>> Did you use proot / dbp or anything else which could affect the build result?
>> 
>> timo
>> 
>
> My build setup on this machine is similar to the ones I was previously
> using which worked ok (slight differences in paths but that shouldn't affect
> anything in a ports build). No proot, I normally use dpb, but get the same
> results with a manual "make".
>
> Looks similar to (same as?) this problem which aja@ ran into, but I don't
> know what happened with that ..
> https://marc.info/?l=openbsd-ports-cvs&m=154340876315118&w=2

I don't remember if there was any solution to that.
As Gerbil uses Gambit scheme as a backend, could the compilation flags of that
affect the Gerbil build?
Did you build the Gambit package yourself or did you use package?
Reading Gambit's INSTALL.txt:
  "Note that some C compilers generate incorrect code when
  compiling Gambit with --enable-c-opt, notably GCC 4.6.0 .  So the
  --enable-c-opt option should be used with great care."

Most of the Gambit documentation seems to recommend to use GCC when compiling
it so I don't know if LLVM gives some issue with it.

Could you test what your gxi is gives when executing:
$ cat < /tmp/test.ss  
  
> (import :std/misc/ports)
> (for-each (lambda (l)
>  (display l) (newline))
> (read-file-lines 
> "/usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/src/gerbil/compiler.ss"))
> EOF

/usr/ports/pobj/gerbil-0.15.1/gerbil-0.15.1/bin/gxi /tmp/test.ss

Timo

Re: lang/gerbil build failures on i386

2019-08-03 Thread Stuart Henderson 
On 2019/08/03 14:36, Timo Myyrä wrote:
> Stuart Henderson  writes:
> 
> > I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any ideas?
> >
> > $ [...] ./build.sh tags 
> >  <
> > [*] Build gerbil tags
> > TAG gerbil/compiler/base.ss
> > TAG gerbil/compiler/compile.ss
> > TAG gerbil/compiler/driver.ss
> > TAG gerbil/compiler/optimize-ann.ss
> > TAG gerbil/compiler/optimize-base.ss
> > TAG gerbil/compiler/optimize-call.ss
> > TAG gerbil/compiler/optimize-top.ss
> > TAG gerbil/compiler/optimize-xform.ss
> > TAG gerbil/compiler/optimize.ss
> > TAG gerbil/compiler/ssxi.ss
> > TAG gerbil/compiler.ss
> > *** ERROR -- (Argument 2) Out of range
> > (vector-ref
> >  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> gambc 
> > compiler" "package: gerbil" "namespace:...
> >  28)
> > *** ERROR; build failed
> >
> >
> > I'm building on new hardware, but other ports are all building ok.
> >
> > This is repeatable (either rerunning ./build.sh tags or making a whole clean
> > build from ports).
> >
> > Any ideas?
> 
> I just tested Gerbil port on new i386 vm host and it did build successfully.
> I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
> /usr/ports/lang/gerbil && make".
> 
> Did you use proot / dbp or anything else which could affect the build result?
> 
> timo
> 

My build setup on this machine is similar to the ones I was previously
using which worked ok (slight differences in paths but that shouldn't affect
anything in a ports build). No proot, I normally use dpb, but get the same
results with a manual "make".

Looks similar to (same as?) this problem which aja@ ran into, but I don't
know what happened with that ..
https://marc.info/?l=openbsd-ports-cvs&m=154340876315118&w=2

Re: lang/gerbil build failures on i386

2019-08-03 Thread Timo Myyrä 
Stuart Henderson  writes:

> I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any ideas?
>
> $ [...] ./build.sh tags   
><
> [*] Build gerbil tags
> TAG gerbil/compiler/base.ss
> TAG gerbil/compiler/compile.ss
> TAG gerbil/compiler/driver.ss
> TAG gerbil/compiler/optimize-ann.ss
> TAG gerbil/compiler/optimize-base.ss
> TAG gerbil/compiler/optimize-call.ss
> TAG gerbil/compiler/optimize-top.ss
> TAG gerbil/compiler/optimize-xform.ss
> TAG gerbil/compiler/optimize.ss
> TAG gerbil/compiler/ssxi.ss
> TAG gerbil/compiler.ss
> *** ERROR -- (Argument 2) Out of range
> (vector-ref
>  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> gambc 
> compiler" "package: gerbil" "namespace:...
>  28)
> *** ERROR; build failed
>
>
> I'm building on new hardware, but other ports are all building ok.
>
> This is repeatable (either rerunning ./build.sh tags or making a whole clean
> build from ports).
>
> Any ideas?

I just tested Gerbil port on new i386 vm host and it did build successfully.
I didn't do anything special, "pkg_add git gambit libxml sqlite3 && cd
/usr/ports/lang/gerbil && make".

Did you use proot / dbp or anything else which could affect the build result?

timo

Re: lang/gerbil build failures on i386

2019-08-02 Thread Timo Myyrä 
Hmm, i recall I've seen this before but I don't remember what it was. I'll look 
into it.

Timo

On Fri, Aug 2, 2019, at 20:00, Stuart Henderson wrote:
> I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any ideas?
> 
> $ [...] ./build.sh tags 
>  <
> [*] Build gerbil tags
> TAG gerbil/compiler/base.ss
> TAG gerbil/compiler/compile.ss
> TAG gerbil/compiler/driver.ss
> TAG gerbil/compiler/optimize-ann.ss
> TAG gerbil/compiler/optimize-base.ss
> TAG gerbil/compiler/optimize-call.ss
> TAG gerbil/compiler/optimize-top.ss
> TAG gerbil/compiler/optimize-xform.ss
> TAG gerbil/compiler/optimize.ss
> TAG gerbil/compiler/ssxi.ss
> TAG gerbil/compiler.ss
> *** ERROR -- (Argument 2) Out of range
> (vector-ref
>  #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> 
> gambc compiler" "package: gerbil" "namespace:...
>  28)
> *** ERROR; build failed
> 
> 
> I'm building on new hardware, but other ports are all building ok.
> 
> This is repeatable (either rerunning ./build.sh tags or making a whole clean
> build from ports).
> 
> Any ideas?
> 
>

lang/gerbil build failures on i386

2019-08-02 Thread Stuart Henderson 
I'm seeing gerbil build failing in "Build gerbil tags" on i386. Any ideas?

$ [...] ./build.sh tags 
 <
[*] Build gerbil tags
TAG gerbil/compiler/base.ss
TAG gerbil/compiler/compile.ss
TAG gerbil/compiler/driver.ss
TAG gerbil/compiler/optimize-ann.ss
TAG gerbil/compiler/optimize-base.ss
TAG gerbil/compiler/optimize-call.ss
TAG gerbil/compiler/optimize-top.ss
TAG gerbil/compiler/optimize-xform.ss
TAG gerbil/compiler/optimize.ss
TAG gerbil/compiler/ssxi.ss
TAG gerbil/compiler.ss
*** ERROR -- (Argument 2) Out of range
(vector-ref
 #(";;; -*- Gerbil -*-" ";;; (C) vyzo at hackzen.org" ";;; gerbil -> gambc 
compiler" "package: gerbil" "namespace:...
 28)
*** ERROR; build failed


I'm building on new hardware, but other ports are all building ok.

This is repeatable (either rerunning ./build.sh tags or making a whole clean
build from ports).

Any ideas?