Mailing Lists: October 2020

Friday, 30 October 2020

Re: [gccsdk] Cross-compiling header issues

On October 29, 2020, Lee Noar <lee.noar@sky.com> wrote:

On 26/10/2020 13:13, Dominic Hamon wrote:
> Hello
>
> I'm embarking on my first attempt to cross-compile something for riscos.
> I have the environment all set up and figured out how to make the
> project, but i'm not sure what the appropriate fix is for an issue:
>
> The project in question (https://github.com/google/benchmark) runs a
> check at build time to see which regex engine is available (std::regix,
> posix regex, or gnu posix regex). It does this by compiling some test
> programs and seeing which succeeds. The issue is that none do for riscos
> (yet).
>
> The closest I get is with the posix regex version, which includes
> `regex.h`. This fails with the error:
>
> $ $CXX posix_regex.cpp
> In file included from posix_regex.cpp:1:0:
> /home/dominic/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/include/regex.h:56:2:
> error: 'size_t' does not name a type
>
> I believe I could fix this by including <sys/types.h> in the crosslib's
> regex.h (linux does this
> https://code.woboq.org/linux/include/regex.h.html#23) but is this
> appropriate? It seems like the right fix to me as regex.h shouldn't be
> using types that haven't been declared.
>
> Would this change be acceptable?

It does sound like regex.h should be including sys/types.h. If you make
this change locally in your environment, does the project build? If so,
then I will commit it.

It does, yes.

There are some other oddities I'm finding in the crosslib headers around things like definitions of strtoul not being in the std namespace, but i wonder if that's related to it not fully supporting C++11?

Thanks,
Lee.

_______________________________________________
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

Thursday, 29 October 2020

Re: [gccsdk] Cross-compiling header issues

On 26/10/2020 13:13, Dominic Hamon wrote:
> Hello
>
> I'm embarking on my first attempt to cross-compile something for riscos.
> I have the environment all set up and figured out how to make the
> project, but i'm not sure what the appropriate fix is for an issue:
>
> The project in question (https://github.com/google/benchmark) runs a
> check at build time to see which regex engine is available (std::regix,
> posix regex, or gnu posix regex). It does this by compiling some test
> programs and seeing which succeeds. The issue is that none do for riscos
> (yet).
>
> The closest I get is with the posix regex version, which includes
> `regex.h`. This fails with the error:
>
> $ $CXX posix_regex.cpp
> In file included from posix_regex.cpp:1:0:
> /home/dominic/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/include/regex.h:56:2:
> error: 'size_t' does not name a type
>
> I believe I could fix this by including <sys/types.h> in the crosslib's
> regex.h (linux does this
> https://code.woboq.org/linux/include/regex.h.html#23) but is this
> appropriate? It seems like the right fix to me as regex.h shouldn't be
> using types that haven't been declared.
>
> Would this change be acceptable?

It does sound like regex.h should be including sys/types.h. If you make
this change locally in your environment, does the project build? If so,
then I will commit it.

Thanks,
Lee.

_______________________________________________
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

Monday, 26 October 2020

[gccsdk] Cross-compiling header issues

Hello

I'm embarking on my first attempt to cross-compile something for riscos. I have the environment all set up and figured out how to make the project, but i'm not sure what the appropriate fix is for an issue:

The project in question (https://github.com/google/benchmark) runs a check at build time to see which regex engine is available (std::regix, posix regex, or gnu posix regex). It does this by compiling some test programs and seeing which succeeds. The issue is that none do for riscos (yet).

The closest I get is with the posix regex version, which includes `regex.h`. This fails with the error:

$ $CXX posix_regex.cpp
In file included from posix_regex.cpp:1:0:
/home/dominic/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/include/regex.h:56:2: error: 'size_t' does not name a type

I believe I could fix this by including <sys/types.h> in the crosslib's regex.h (linux does this https://code.woboq.org/linux/include/regex.h.html#23) but is this appropriate? It seems like the right fix to me as regex.h shouldn't be using types that haven't been declared.

Would this change be acceptable?

Thanks
- dominic

Friday, 23 October 2020

Re: [gccsdk] Compiling from a 'flat' layout?

On 22/10/2020 11:01, Chris Johns wrote:
> Hello
>
> I am sure this has come up before, but is there any option to get GCC
> running natively on RISC OS to use use a 'flat' file layout? eg. "foo/c"
> rather than a file called foo in the 'c' directory.
>
> I can use gcc -xc foo/c, but if it does a #include "foo.h" it won't find
> foo/h.

I think the main problem is that it's all or nothing. It's possible
(although I haven't tried) that unsetting all the $sfix variables, eg,
UnixEnv$gcc$sfix (or at least removing .h) may cause GCC to use a flat
layout, *but* that would also apply to all libraries too including
UnixLib so you would have to flatten those as well.

Lee.

_______________________________________________
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] DDEUtils

On 22/10/2020 19:19, Chris Johns wrote:
> If I try to run python3 or gcc with a *Prefix set, they just hang. No error, just don't do anything.
>
> Is there something with gcc compiled code (or shared libs, unixlib or some other part of the setup) that upsets DDEUtils?
>
> I've gone down this particular rabbit hole trying to get python to compile something from setup.py and my theory is it's using subprocess to do something which changes the csd which on risc os is global.

UnixLib does make use of DDEUtils and manipulates the prefix within
vfork (libunixlib/sys/vfork.c), which I believe is commonly used for
subprocesses. It looks like it's preserving and restoring the parent's
prefix around the child call. If DDEUtils provides per task command
lines, then technically vfork children are all the same task and have
the same prefix, hence why vfork need to preserve it.

Not sure any of that actually helps explain your problem though.

Lee.

_______________________________________________
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

Thursday, 22 October 2020

[gccsdk] DDEUtils

If I try to run python3 or gcc with a *Prefix set, they just hang. No error, just don't do anything.

Is there something with gcc compiled code (or shared libs, unixlib or some other part of the setup) that upsets DDEUtils?

I've gone down this particular rabbit hole trying to get python to compile something from setup.py and my theory is it's using subprocess to do something which changes the csd which on risc os is global.

Thanks,

Chris

_______________________________________________
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

[gccsdk] Compiling from a 'flat' layout?

Hello

I am sure this has come up before, but is there any option to get GCC
running natively on RISC OS to use use a 'flat' file layout? eg. "foo/c"
rather than a file called foo in the 'c' directory.

I can use gcc -xc foo/c, but if it does a #include "foo.h" it won't find
foo/h.

Cheers

Chris

_______________________________________________
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, 21 October 2020

Re: [gccsdk] Trying to build sqlite

That's curious. I just tried again, and now it works... I tried several times yesterday without success, but today it just works. I tried your version with -v initially but I suppose that's just verbose so that shouldn't matter. Tried it as well without -v but it also works then, not surprisingly.

Oh well, at least it works now... I suppose it was the restart in some form that did the trick.

Thanks for your upload, that was most kind, but it doesn't seem to be needed anymore... :)

Cheers,
Jan-Jaap

On 21 October 2020 09:50:09 CEST, David Pitt <pittdj@pittdj.co.uk> wrote:

jjvdgeer@vfemail.net, on 20 Oct, wrote:

Hi

I'm trying to build libsqlite but it's failing. According to  
subversion there was activity on libsqlite3-0 last august, so I  
suppose it should probably build and the problem is at my end, 

libsqlite3-0 has built here, and with 

RO_SHAREDLIBS=yes

in the file

gccsdk/build/build-setvars

a !SharedLibs was also built.

The build command was :-

cd build
../autobuilder/build -v libsqlite3-0

Revision is 7437 and the host is Ubuntu 18.04

The builds are here :-

http://www.pittdj.co.uk/temp/libsqlite3_3.27.2-2_arm.zip
http://www.pittdj.co.uk/temp/libsqlite3-dev_3.27.2-2_arm.zip

but I'm not sure how to fix it... Any suggestions?

Unhelpfully this offers no clues as to what might be wrong.

--
Sent from my Gemini PDA with the Airmail® app. Please excuse my verboseness - I have a great keyboard and just cannot resist. Get a Gemini PDA from Planet and type on the move! www.planetcom.co.uk

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas! 15GB disk space!
Commercial and Bulk Mail Options!

Re: [gccsdk] Trying to build sqlite

jjvdgeer@vfemail.net, on 20 Oct, wrote:

> Hi
>
> I'm trying to build libsqlite but it's failing. According to
> subversion there was activity on libsqlite3-0 last august, so I
> suppose it should probably build and the problem is at my end,

libsqlite3-0 has built here, and with

RO_SHAREDLIBS=yes

in the file

gccsdk/build/build-setvars

a !SharedLibs was also built.

The build command was :-

cd build
../autobuilder/build -v libsqlite3-0

Revision is 7437 and the host is Ubuntu 18.04

The builds are here :-

http://www.pittdj.co.uk/temp/libsqlite3_3.27.2-2_arm.zip
http://www.pittdj.co.uk/temp/libsqlite3-dev_3.27.2-2_arm.zip

> but I'm not sure how to fix it... Any suggestions?

Unhelpfully this offers no clues as to what might be wrong.

--
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

Tuesday, 20 October 2020

Re: [gccsdk] Trying to build sqlite

Yeah, I agree that seems to be the i underlying problem but I'd expect the build system to take care of that. I built with "./build - d libsqlite3-0", which is pretty much the same way I built other libraries and they did not have this problem.

It's been a while since I last used the autobuilder though but I don't think this is something one usually needs to handle manually in some way.

Cheers,

Jan-Jaap

On 21 October 2020 05:17:26 Alan Williams <ajw@bigblue.net.au> wrote:

Jan-jap,
Before anybody who can actually help in a practical way weighs in, "undefined reference to `main'" suggests to me that you need to build this as a library not as a executable. So an .so not a .e1f should be built.
A library shouldn't have a main() entry point.
Alan

From: <gcc-bounces@gccsdk.riscos.info> on behalf of <jjvdgeer@vfemail.net>
Date: Wednesday, 21 October 2020 at 7:27 am
To: <gcc@gccsdk.riscos.info>
Subject: [gccsdk] Trying to build sqlite

Hi

I'm trying to build libsqlite but it's failing. According to subversion there was activity on libsqlite3-0 last august, so I suppose it should probably build and the problem is at my end, but I'm not sure how to fix it... Any suggestions?
libtool: link: /home/jjvdgeer/gccsdk/env/arm-unknown-riscos-gcc -O3 -DSQLITE_OS_UNIX=1 -I. -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/src -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/rtree -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/icu -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/fts3 -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/async -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/session -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/userauth -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DHAVE_READLINE=1 -DHAVE_EDITLINE=0 -DSQLITE_ENABLE_JSON1 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_EXPLAIN_COMMENTS -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION -DSQLITE_ENABLE_STMTVTAB -DSQLITE_ENABLE_DBPAGE_VTAB -DSQLITE_ENABLE_DBSTAT_VTAB -DSQLITE_ENABLE_OFFSET_SQL_FUNC -DSQLITE_ENABLE_DESERIALIZE -DSQLITE_INTROSPECTION_PRAGMAS -o sqlite3,e1f shell.c sqlite3.c -lreadline -ldl -Wl,-rpath -Wl,/home/jjvdgeer/gccsdk/env/lib
libtool: compile: /home/jjvdgeer/gccsdk/env/arm-unknown-riscos-gcc -O3 -DSQLITE_OS_UNIX=1 -I. -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/src -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/rtree -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/icu -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/fts3 -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/async -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/session -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/userauth -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DSQLITE_TEMP_STORE=1 -c sqlite3.c -o sqlite3.o >/dev/null 2>&1
/home/jjvdgeer/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/crt0.o: In function `crt1_data':
crt0.S:(.data+0x14): undefined reference to `main'
collect2: error: ld returned 1 exit status
make: *** [Makefile:650: sqlite3,e1f] Error 1
make: *** Waiting for unfinished jobs....

Cheers,
Jan-Jaap

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas! 15GB disk space!
Commercial and Bulk Mail Options!

Re: [gccsdk] Trying to build sqlite

Jan-jap,

Before anybody who can actually help in a practical way weighs in, "undefined reference to `main'" suggests to me that you need to build this as a library not as a executable. So an .so not a .e1f should be built.

A library shouldn't have a main() entry point.

Alan

From: <gcc-bounces@gccsdk.riscos.info> on behalf of <jjvdgeer@vfemail.net>
Date: Wednesday, 21 October 2020 at 7:27 am
To: <gcc@gccsdk.riscos.info>
Subject: [gccsdk] Trying to build sqlite

Hi

I'm trying to build libsqlite but it's failing. According to subversion there was activity on libsqlite3-0 last august, so I suppose it should probably build and the problem is at my end, but I'm not sure how to fix it... Any suggestions?

libtool: link: /home/jjvdgeer/gccsdk/env/arm-unknown-riscos-gcc -O3 -DSQLITE_OS_UNIX=1 -I. -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/src -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/rtree -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/icu -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/fts3 -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/async -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/session -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/userauth -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DHAVE_READLINE=1 -DHAVE_EDITLINE=0 -DSQLITE_ENABLE_JSON1 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_EXPLAIN_COMMENTS -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION -DSQLITE_ENABLE_STMTVTAB -DSQLITE_ENABLE_DBPAGE_VTAB -DSQLITE_ENABLE_DBSTAT_VTAB -DSQLITE_ENABLE_OFFSET_SQL_FUNC -DSQLITE_ENABLE_DESERIALIZE -DSQLITE_INTROSPECTION_PRAGMAS -o sqlite3,e1f shell.c sqlite3.c -lreadline -ldl -Wl,-rpath -Wl,/home/jjvdgeer/gccsdk/env/lib

libtool: compile: /home/jjvdgeer/gccsdk/env/arm-unknown-riscos-gcc -O3 -DSQLITE_OS_UNIX=1 -I. -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/src -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/rtree -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/icu -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/fts3 -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/async -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/session -I/home/jjvdgeer/gccsdk/autobuilder/libsqlite3-0/sqlite3-3.27.2/ext/userauth -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DSQLITE_TEMP_STORE=1 -c sqlite3.c -o sqlite3.o >/dev/null 2>&1

/home/jjvdgeer/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/crt0.o: In function `crt1_data':

crt0.S:(.data+0x14): undefined reference to `main'

collect2: error: ld returned 1 exit status

make: *** [Makefile:650: sqlite3,e1f] Error 1

make: *** Waiting for unfinished jobs....

Cheers,
Jan-Jaap

[gccsdk] Trying to build sqlite

/home/jjvdgeer/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/lib/crt0.o: In function `crt1_data':

crt0.S:(.data+0x14): undefined reference to `main'

collect2: error: ld returned 1 exit status

make: *** [Makefile:650: sqlite3,e1f] Error 1

make: *** Waiting for unfinished jobs....

Cheers,
Jan-Jaap