NetSurf 3.3 released

[wawrzon]

hi chris, im back to setting up netsurf compile on another machine. however im already in trouble here on debian jessie 32bit under vmware, building the toolchain for 68k. i know there are precompiled ones but maybe this is a bug in interaction with newer flex or bison versions im not able to figure out, nor downgrade and it would be worth fixing:

Code: [Select]

...gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  -Wno-error  -DHAVE_CONFIG_H    -I. -I. -I/home/wawa/toolchains/m68k-unknown-amigaos/builddir/srcdir/gcc/gcc -I/home/wawa/toolchains/m68k-unknown-amigaos/builddir/srcdir/gcc/gcc/. -I/home/wawa/toolchains/m68k-unknown-amigaos/builddir/srcdir/gcc/gcc/../include  c-parse.c -o c-parse.o
c-parse.y: In function %&$#?@!%&$#?@!%&$#?@!8216;yyparse%&$#?@!%&$#?@!%&$#?@!8217;:
c-parse.y:594:16: error: %&$#?@!%&$#?@!%&$#?@!8216;YYLEX%&$#?@!%&$#?@!%&$#?@!8217; undeclared (first use in this function)
       yychar = YYLEX;
                ^
c-parse.y:594:16: note: each undeclared identifier is reported only once for each function it appears in
Makefile:792: recipe for target 'c-parse.o' failed


[chris]

hi chris, im back to setting up netsurf compile on another machine. however im already in trouble here on debian jessie 32bit under vmware, building the toolchain for 68k. i know there are precompiled ones but maybe this is a bug in interaction with newer flex or bison versions im not able to figure out, nor downgrade and it would be worth fixing:

Code: [Select]


...gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  -Wno-error  -DHAVE_CONFIG_H    -I. -I. -I/home/wawa/toolchains/m68k-unknown-amigaos/builddir/srcdir/gcc/gcc -I/home/wawa/toolchains/m68k-unknown-amigaos/builddir/srcdir/gcc/gcc/. -I/home/wawa/toolchains/m68k-unknown-amigaos/builddir/srcdir/gcc/gcc/../include  c-parse.c -o c-parse.o
c-parse.y: In function %&$#?@!%&$#?@!%&$#?@!8216;yyparse%&$#?@!%&$#?@!%&$#?@!8217;:
c-parse.y:594:16: error: %&$#?@!%&$#?@!%&$#?@!8216;YYLEX%&$#?@!%&$#?@!%&$#?@!8217; undeclared (first use in this function)
       yychar = YYLEX;
                ^
c-parse.y:594:16: note: each undeclared identifier is reported only once for each function it appears in
Makefile:792: recipe for target 'c-parse.o' failed


Appears to be the same thing Tygre reported under Cygwin:
http://wiki.netsurf-browser.org/Documentation/BuildingForAmigaOS#Building_under_Cygwin

Replace YYLEX with yylex() in c-parse.in

I'm reluctant to change it in the repo in case it breaks the CI builds.

[wawrzon]

might be worth to check though, maybe ask up on ml first? or risk a nightly in order to reverse later if it fails?

because as this seems to be a generated file (its in build folder) when i change it i need to run make again over already patched source and even though i refuse to re apply or reverse patch, the build fails at some later point due to some skipped hunk.

namely here:

Code: [Select]

patching file libstdc++-v3/configure
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file libstdc++-v3/configure.rej
Makefile:140: recipe for target '/home/wawa/toolchains/m68k-unknown-amigaos/builddir/build-steps/srcdir-step3.d' failed
make: *** [/home/wawa/toolchains/m68k-unknown-amigaos/builddir/build-steps/srcdir-step3.d] Error 1


[chris]

might be worth to check though, maybe ask up on ml first? or risk a nightly in order to reverse later if it fails?

because as this seems to be a generated file (its in build folder) when i change it i need to run make again over already patched source and even though i refuse to re apply or reverse patch, the build fails at some later point due to some skipped hunk.

It's generated from c-parse.in

You could create a patch and stick it in recipes/patches, or put the modified file wholesale in recipes/files

[wawrzon]

or put the modified file wholesale in recipes/files

looks like its been solved like that. perhaps it can be solved this way upstream for amiga target for the time being, even if it seems to be sub optimal.

[chris]

looks like its been solved like that. perhaps it can be solved this way upstream for amiga target for the time being, even if it seems to be sub optimal.

I've created a patch in branch chris/yylex, but I haven't tested here (where YYLEX was working fine), nor have I updated my VM which I never update for fear of breaking something, to see whether YYLEX still works there without this patch.

[wawrzon]

when i read through this thread it makes me laugh what problems i caused but its all not that self explanatory. i have now toolchain and sdk installed in place, and could compile all libs with

sudo make -C libxxx HOST=m68k-unknown-amigaos

they compile to

/dev-netsurf/workspace/libxxx/build-i586-linux-gnu-m68k-unknown-amigaos-release-lib-static

instead to

/opt/netsurf/m68k-unknown-amigaos/cross/m68k-unknown-amigaos/lib

where they i suppose belong. need to figure that out rather to copy by hand i guess..

[chris]

when i read through this thread it makes me laugh what problems i caused but its all not that self explanatory. i have now toolchain and sdk installed in place, and could compile all libs with

sudo make -C libxxx HOST=m68k-unknown-amigaos

they compile to

/dev-netsurf/workspace/libxxx/build-i586-linux-gnu-m68k-unknown-amigaos-release-lib-static

instead to

/opt/netsurf/m68k-unknown-amigaos/cross/m68k-unknown-amigaos/lib

where they i suppose belong. need to figure that out rather to copy by hand i guess..

Simply do a:
sudo make -C libxxx HOST=m68k-unknown-amigaos install
afterwards and they'll end up in the right place.
(you don't need to 'sudo' the plain make, in fact you probably shouldn't, only 'sudo' the install)

[wawrzon]

looks like pkg config variable is not specified, i guess it should point directly to where .pc files are, but i dont think it should be hardcoded in the makefile, it hasnt even work when i tried to add it by hand on os3 subsection.

[chris]

looks like pkg config variable is not specified, i guess it should point directly to where .pc files are, but i dont think it should be hardcoded in the makefile, it hasnt even work when i tried to add it by hand on os3 subsection.

There's an env-var for pkgconfig that it should be using IIRC.  Never seen any problems with that, maybe the library it is looking for isn't installed?

[wawrzon]

There's an env-var for pkgconfig that it should be using IIRC.  Never seen any problems with that, maybe the library it is looking for isn't installed?

PKG_CONFIG_PATH..
it doesnt seem to be set.
the lib is installed to /opt/netsurf/lib, as i previously said.
sorry, was out in the wild, so didnt made any progress on that since yesterday.

[wawrzon]

just set that env variable by hand to correct location. but i think it should be set by a makefile, if not the each and every one library makefile, then maybe a higher level makefile/script that would build all dependencies in a row and to a correct directory. or maybe should it be specified in a netsurf makefile itself? what do you think, chris?

now it builds, but obviously doesnt get past duktape. i think, time to consult dnadnl

[chris]

just set that env variable by hand to correct location. but i think it should be set by a makefile, if not the each and every one library makefile, then maybe a higher level makefile/script that would build all dependencies in a row and to a correct directory. or maybe should it be specified in a netsurf makefile itself? what do you think, chris?

The default locations should be set when pkg-config (or build-essential or whatever) is installed. NetSurf might add to it in a makefile, not sure, never had to change it.

[wawrzon]

netsurf should provide nightly builds like aros, then build system could be consistent and proven working out of the box at all times. and amigaos3 should be added to the official target list of course;)

[chris]

netsurf should provide nightly builds like aros, then build system could be consistent and proven working out of the box at all times.

http://ci.netsurf-browser.org/builds/

and amigaos3 should be added to the official target list of course;)

http://wiki.netsurf-browser.org/NetSurf_3.6#Amiga