Am 19.02.21 um 09:36 schrieb Klaus Ziegler - owner of sunfreeware.de:
Hi,
I'm currently compiling gcc-7.5.0-il-0 on SPARC in oi-userland,
while this fact isn't SPARC only, I'm a little bit puzzled about it.
If you do a "make build" and watch the configure process in
the first gmp subdir you'll see the following:
configure: creating cache ./config.cache
checking build system type... i386-pc-solaris2.11
checking host system type... none-pc-solaris2.11 <--- ?
4 lines later:
configure: WARNING: using cross tools not prefixed with host triplet
again 6 lines later there happens a real mess:
configure: WARNING: the "none" host is obsolete, use --disable-assembly
checking ABI=standard
this "--disable-assembly" line shouldn't apear at all and it should say
checking ABI=32, or if you are compiling gcc-10 ABI=64.
To bring it to the point, all of this also happens on gcc-10!
It looks like that the whole thing gmp is about - "doing assembly
acceleration" isn't given trough to all of our oi-userland gcc builds!
If you have a look in directory: build/i86/gmp/mpn after configure
has finished it's work, you won't see any *.asm links into the gmp
sources, this of course proves that non of the assembler code will
be used in this gmp build.
The problem is the top-level Makefile.in in the gcc source tree,
I'm sure that the speed of modern x86 systems is the source
of the problem that nobody has seen this before, if you do work
on a 20 year old Ultra60 you have more of chance to see this :-)
I think, the reason that the top-level Makefile.in is designed this way,
is the fact that gcc can be cross-compiled, which we won't do at all
in any of gcc oi-userland builds.
I've written patches for gcc-7 and gcc-10 to remediate this, I'm
fairly new to OI processes, so I just don't know how to integrate
a change like this, while I did my best to get the brand10 bug fixed
in ticket #13562, shall I just open a new ticket for this and don't
assign it to myself? or what shall I do? - I just need someone to take
The best way to get things integrated is to create PR's (pull requests)
against oi-userland and wait for comments resp. requests for changes.
In the past people have fixed problems on SPARC by creating PR's that
have been merged by the oi-userland maintainers.
The only thing we request for SPARC related changes: either proof or
convince us that it doesn't harm the x64 builds.
If your changes also involve x64 we can check more easily (eg. albeit I
have old US-III SPARC machines, I only run x64 with OpenIndiana).
I can assure you that all kinds of PR's will be highly appreciated!
I assume that you already cloned our OpenIndiana/oi-userland github
repository into your own
and thus are familiar with the general PR process. If not, I can help
you with it (even in German if you prefer that).
For your concrete problem I would wait until alarcher finds some spare
cycles. He is our specialist in that area. He may have some comments.
Anyway, if you provide a PR it will be easier to discuss and understand
the issues you have detected.
me by the hand and guide me. If someone want's to try out the
patches I've done, please reply to me and I'm more than happy
to provide them, I just didn't attach them to bother anybody in
the community. BTW. the performace gain on such an old SPARC
is really sensible :-)
Please try to use the PR process (accompanied with bug tickets). As I
wrote above: if you need any help to get there, feel free to ask.
With PR's it's a lot easier (read: less work) for the maintainers.
Best regards,
Andreas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
