Thursday, 31 August 2017

Re: [gccsdk] wget 1.19.1 tries to write a logfile

Ralph Corderoy, on 30 Aug, wrote:

> Hi Theo,
>
> > It is still worth commenting on upstream bug trackers - they won't
> > know what RISC OS is, but if the bug is not a RISC OS specific one
> > then the bug report is still relevant.
>
> It might be that RISC OS triggers it in a similar way to the odd set up
> on that bug report.
>
> src/log.c:
> 955 static void
> 956 check_redirect_output (void)
> 957 {
> 958 #ifndef WINDOWS
> 959 /* If it was redirected already to log file by SIGHUP, SIGUSR1
or -o parameter,
> 960 * it was permanent.
> 961 * If there was no SIGHUP or SIGUSR1 and shell is interactive
> 962 * we check if process is fg or bg before every line is
printed.*/
> 963 if (!redirect_request_signal_name && shell_is_interactive &&
!opt.lfilename)
> 964 {
> → 965 if (tcgetpgrp (STDIN_FILENO) != getpgrp ())
> 966 {
> 967 /* Process backgrounded */
> → 968 redirect_output (true,NULL);
> 969 }
>
> I haven't run this code, but I wonder if 965 is true. If Kevin is happy
> to modify the source and re-build then he might be able to tell that 968
> executes.

Perhaps this :-

https://fossies.org/diffs/wget/1.18_vs_1.19/ChangeLog-diff.html

2016-10-21 losgrandes <pwajda@gmail.net.pl>

Fixes #45790: wget prints it's progress even when background
* src/log.c: Use tcgetpgrp(STDIN_FILENO) != getpgrp() to determine when
to print to STD* or logfile.
Deprecate log_request_redirect_output function.
Use different file handles for STD* and logfile, to easily switch betwe en
them when changing fg/bg.
* src/log.h: Make redirect_output function externally linked.
* src/main.c: Don't use deprecated log_request_redirect_output function.
Use redirect_output instead.
* src/mswindows.c: Don't use deprecated log_request_redirect_output
function. Use redirect_output instead.
--
David Pitt

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] wget 1.19.1 tries to write a logfile

Kevin Wells, on 28 Aug, wrote:

> Hi
>
> When using wget 1.19.1 with the quiet option selected I get the
> following message:
>
> Redirecting output to 'wget-log.##'
>
> The ## is a number that increases each time.
>
> The file is a log of the connection details of wget.
>
> Previous versions did not display this.

Having done further tests I am seeing the apparently spurious
'wget-log' both with and without the '-q' flag. This is both with the
currency command line example given and a simple wget from my site.

*wget --version
GNU Wget 1.19.1 built on riscos.

*wget http://www.pittdj.co.uk/temp/temp.htm

Redirecting output to 'wget-log'.
*
*wget http://www.pittdj.co.uk/temp/temp.htm -q

Redirecting output to 'wget-log.1'.
*

The '-q' flag results in an empty 'wget-log' file.


Using wget 1.18, home built here with autobuilder revision 7118, the log
output defaults to the screen as expected with no redrection.

wget 1.19.1-3ubuntu1 on Ubuntu 17.10 (development branch) does not redirect
either.

FWIW HTH
--
David Pitt

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Wednesday, 30 August 2017

Re: [gccsdk] wget 1.19.1 tries to write a logfile

Hi Theo,

> It is still worth commenting on upstream bug trackers - they won't
> know what RISC OS is, but if the bug is not a RISC OS specific one
> then the bug report is still relevant.

It might be that RISC OS triggers it in a similar way to the odd set up
on that bug report.

src/log.c:
955 static void
956 check_redirect_output (void)
957 {
958 #ifndef WINDOWS
959 /* If it was redirected already to log file by SIGHUP, SIGUSR1 or -o parameter,
960 * it was permanent.
961 * If there was no SIGHUP or SIGUSR1 and shell is interactive
962 * we check if process is fg or bg before every line is printed.*/
963 if (!redirect_request_signal_name && shell_is_interactive && !opt.lfilename)
964 {
→ 965 if (tcgetpgrp (STDIN_FILENO) != getpgrp ())
966 {
967 /* Process backgrounded */
→ 968 redirect_output (true,NULL);
969 }

I haven't run this code, but I wonder if 965 is true. If Kevin is happy
to modify the source and re-build then he might be able to tell that 968
executes.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] wget 1.19.1 tries to write a logfile

On 2017-08-29 18:23, Kevin Wells wrote:
> In message <mpro.ovgbl40050dql02nh.pittdj@pittdj.co.uk>
> David Pitt <pittdj@pittdj.co.uk> wrote:

>> Adding -o null: to the command line stops the unwanted wget-log
>> appearing.

> Thanks for that, so I guess the fix wil have to come from the upstream?
>
> I don't want to have to update about half a dozen of my applications if
> I don;t have to.

Would, say, renaming the binary to 'wget2' and defining an alias for
wget so
that it executes wget2 with the "-o null:" bit added get around that for
the
moment?

--
Jeremy Nicoll - my opinions are my own

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] wget 1.19.1 tries to write a logfile

On Tue, Aug 29, 2017 at 06:23:02PM +0100, Kevin Wells wrote:
> Thanks for that, so I guess the fix wil have to come from the upstream?

Yes. We don't generally have the manpower to curate patches that diverge
from upstream, apart from anything necessary to make it build on RISC OS.
We should be able, however, to turn around a new upstream build fairly
rapidly - so at such time that a new version is released we can produce a
new RISC OS build rapidly (though testing it is rather more difficult).

It is still worth commenting on upstream bug trackers - they won't know what
RISC OS is, but if the bug is not a RISC OS specific one then the bug report
is still relevant. Though it seems there has been no activity on this one
since it was reported in June.

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Fwd: Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

in the amigaos includes dir in your inline dir, you need the new macros.h file (change jsr a6@(%1.w) to jsr -%1(a6)).work too on older gcc,because ggc use now motorola ASM output, thats standard on amiga.also gcc main source dont generate correct code when not use motorola output.



compile of the attached 4.3.2 sources.I test on cygwin with 3.4 compilers:



important do cd to objdir and objdir should be diffrent to source dir or build/gencodes.exe miss error come.

and the vars should set with

export OBJDIR=......

export SRCDIR=......



to your source and object dir.



now type



cd $OBJDIR

$SRCDIR/configure --target=m68k-amigaos --with-cpu=m68040 --prefix=/usr/local/amiga



when its done type



make



when its done



make install DESTDIR=xxxx



best use DESTDIR to a temporary dir, so you see what files are create.

create files are in xxxx/usr/local/amiga



thats all.



************************************************************ steps to build a amigaos GCC from sources from www.gcc.org ************************



Because 68k amiga OS is the only amiga target that is in ggc main source, it is easy to build every version you like.This steps are need



add in gcc-x.x.x/gcc/config.gcc



(search for m68k)



m68k-*-amigaos*)

tmake_file=m68k/t-amigaos

tm_file="${tm_file} m68k/amigaos.h"

tm_p_file="${tm_p_file} m68k/amigaos-protos.h"

tm_defines="TARGET_AMIGAOS TARGET_DEFAULT=0" # 68040

extra_objs=amigaos.o

gnu_ld=yes

;;





in gcc-x.x.x/gcc/config/m68k dir add files (from the 4.3.2 source)



amigaos.h

amigaos.c

t-amigaos

x-amigaos

xm-amigaos.h

amigaos-protos.h

host-amigaos.c



in dir gcc-x.x.x//gcc add file

amigacollect2.c



thats enough to build the gcc.more steps are need, to build the libs, libgcc libstdc++ when you want new



to build libgcc: add in libgcc/config.host 68k cpu and later amigaos.see file from 4.3.2 or use same.





the dir amigaos must add in libstdc++-v3/config (see 4.3.2 source)

now you can compile all.



when you get assembler error in atomicity.h change line with the cas so that, the \n is last char.

"cas.l %0 , %1 , %2 \n"



for build libstdc++ with the crosscompilers you need do this steps too



in libstdc++/configure



after (search for "GLIBCXX_IS_NATIVE=true")



""""

if test $hostos = $targetos -o $targetos = darwin ; then

GLIBCXX_IS_NATIVE=true

fi

;;

""""

add this lines



"""

*-*-amigaos*)

LDFLAGS="${LDFLAGS-ld} -noixemul"

;;

""""

search for "Base decisions on target environment"



""""

# Base decisions on target environment.

case "${host}" in

""""

add this lines

"""

m68k-*-amigaos*)

#os_include_dir="usr/local/amiga/m68k-amigaos/include"

;;

"""

in gccx.x.x/libiberty/configure



after this lines



""""

Use these variables to override the choices made by `configure' or to help

it to find libraries and programs with nonstandard names/locations.



_ACEOF

fi

""""

add this line



LDFLAGS="${LDFLAGS-ld} -noixemul"









if you want build without debug(-g ) type make "CFLAGS=-O2" "LIBCFLAGS=-O2" "LIBCXXFLAGS=-O2" (but dont work i find out)



if you dont like that the whole debug symbols are in the libs, then use strip -g dir(older gcc are build without complete symbols)

also you can choose in amidev in linker options that your program have no debug symbols.





*************************** build 68k to 68k gcc *************************************************************************************+

If you want build a GCC that run on 68k ( MOS OS4 Versions seem too possible, when you have installed the OS4 MOS crosscompilers on cygwin and you choose

---host- mos or OS4 identify)

you need this steps.



Add in file config.host this



m68k-*-amigaos*)

host_xm_file=m68k/xm-amigaos.h

host_xmake_file="${host_xmake_file} m68k/x-amigaos"

//host_xmake_file=m68k/x-amigaos

out_host_hook_obj=host-amigaos.o

;;



prefix /gg use older amiga build for geek gadget, so i use that too

make sure the new libnix is in dir libm020/libnix for best speed

$SRCDIR/configure --host=m68k-amigaos --target=m68k-amigaos --with-cpu=m68040 --prefix=/gg --disable-nls

copy file host-amigaos.c to gccxx/gcc/config/m68k



then type make.



when compile stop with auto-build.h not found, use the file auto-host.h as auto-build.h.thats ok for the 68k compiler build, but to compile full 68k files, use above files



To build gmp and mpfr library under crosscompiler for gcc that run on 68k(normaly not need, use 68k files in lib dir)



go to the dir



type

./configure --host=m68k-amigaos



now type make and look if the the right compiler is used (show 68k m68k-amigaos-gcc -D....)



*************************** binutil build **********************************************************



the binutil files (as,ld) come in usr/local/amiga/m68k-amigaos/bin



copy after this in file bfd/config.bfd



m68*-



this



m68k-*-amigaos)

targ_defvec=amiga_vec

targ_selvecs=aout_amiga_vec

;;



add this lines in file bfd/targets.c



extern const bfd_target amiga_vec;

extern const bfd_target aout_amiga_vec;



in file bfd/configure add after



for vec in $selvecs do

target_size=32

case "$vec" in



this lines.



amiga_vec) tb="$tb amigaos.o amigaoslink.o" ;;

aout_amiga_vec) tb="$tb aout-amiga.o aout32.o stab-syms.o";;



copy files from old binutil



amigaos.c

amigaoslink.c

aout-amiga.c

libamiga.h



to dir bfd



copy file amigaos.h to bfd/hosts



not work because of too old amiga files, to be continue....





every help/report is welcome, you can mail to me at nospamname@web.de-------- Original Message --------
From: Bernd R <nospamname@web.de>
Sent: 30 August 2017 10:00:38 BST
To: Chris Young <chris.young@unsatisfactorysoftware.co.uk>
Subject: Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

Hello Chris

the paths can change with compiler or linker options in makefile. i did not know what change your build have. My gcc port is too very simular to gcc build of other platforms and in the page i give you link, is instruction how can build easy.see attached files. on newer gcc the libs can not compile. there are no programs that need the new libs i know so far. teh build stop with error, after the important thing(the compilers is compile). many ports are done with the GCC 4.5 with full optimize, so it know as stable. but intresting to see if GCC 7.2 give more speed

maybe this build can work with netsurf too. i try to compile 7.2 and let you know. see how easy should possible to build a new version. work with 4.3.2 and 4.5. lets see if can work with 7.2 too



On 29.08.17, you wrote:

> On Tue, 29 Aug 2017 17:28:55 +0200, Bernd R wrote:
>
>> seem the mailing list not work
>> when it show earlier the page but flicker is better, because wait until all is load is boring. so how is it done in windows version ?
>>
>> > A patch to upgrade the toolchain to GCC 4.5 would be greatly
>> > appreciated.
>>
>> GCC 4.5 and 4.3.2 68k for cygwin host in windows you can download here
>>
>> https://sourceforge.net/projects/amiga/files/Compilers/
>>
>> on what system do you compile ?. I have done the 68k ports years
>> ago, and now i have install a vmware ubuntu 7 X64. If this is
>> usefull, i can try to compile gcc this for ubuntu 7.or can try to
>> run cygwin under wine on linux
>
> 64-bit Debian.
>
> GCC needs to be integrated into the toolchain:
> http://git.netsurf-browser.org/toolchains.git/tree/m68k-unknown-amigaos
>
> A "standalone" build of GCC is not helpful as the paths are different.
> When I upgraded to 3.4 I managed to mostly copy across the patches
> from https://github.com/cahirwpz/amigaos-cross-toolchain
> Most of the other ports I've seen for 68k (including a fork of that
> one for gcc6) are an entire repository with the changes integrated.
>
> Whilst that can theoretically be cloned and built within the
> toolchain, it's a pain to have to change everything to accomodate it
> only to have to switch everything around again when the next gcc port
> comes along by somebody else with different ideas on how it should be
> maintained.
>
> My preference would be to go as new as possible so it doesn't have to
> be done again for a long time.
> gcc6 is here: https://github.com/bebbo/gcc
>
> Chris
>
>
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
Regards

Tuesday, 29 August 2017

Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

On Tue, 29 Aug 2017 17:28:55 +0200, Bernd R wrote:

> seem the mailing list not work
> when it show earlier the page but flicker is better, because wait until all is load is boring. so how is it done in windows version ?
>
> > A patch to upgrade the toolchain to GCC 4.5 would be greatly
> > appreciated.
>
> GCC 4.5 and 4.3.2 68k for cygwin host in windows you can download here
>
> https://sourceforge.net/projects/amiga/files/Compilers/
>
> on what system do you compile ?. I have done the 68k ports years
> ago, and now i have install a vmware ubuntu 7 X64. If this is
> usefull, i can try to compile gcc this for ubuntu 7.or can try to
> run cygwin under wine on linux

64-bit Debian.

GCC needs to be integrated into the toolchain:
http://git.netsurf-browser.org/toolchains.git/tree/m68k-unknown-amigaos

A "standalone" build of GCC is not helpful as the paths are different.
When I upgraded to 3.4 I managed to mostly copy across the patches
from https://github.com/cahirwpz/amigaos-cross-toolchain
Most of the other ports I've seen for 68k (including a fork of that
one for gcc6) are an entire repository with the changes integrated.

Whilst that can theoretically be cloned and built within the
toolchain, it's a pain to have to change everything to accomodate it
only to have to switch everything around again when the next gcc port
comes along by somebody else with different ideas on how it should be
maintained.

My preference would be to go as new as possible so it doesn't have to
be done again for a long time.
gcc6 is here: https://github.com/bebbo/gcc

Chris