[oi-dev] gcc builds - no cc1objplus

2021-02-22 Thread Klaus Ziegler - owner of sunfreeware.de

Hi,

is there any reason why we don't provide cc1objplus compiler in gcc builds?
--- Makefile.orig    2021-02-21 21:09:30.515646158 +
+++ Makefile    2021-02-21 21:17:44.199125768 +
@@ -47,7 +47,7 @@
 CONFIGURE_OPTIONS+= --enable-plugins
 CONFIGURE_OPTIONS+= --enable-objc-gc
 CONFIGURE_OPTIONS.i386+= --enable-initfini-array
-CONFIGURE_OPTIONS+= --enable-languages=c,c++,fortran,lto,objc
+CONFIGURE_OPTIONS+= --enable-languages=c,c++,fortran,lto,objc,obj-c++
 CONFIGURE_OPTIONS+= --disable-libitm
 CONFIGURE_OPTIONS+= enable_frame_pointer=yes

maybe just forgotten? however including it does not harm at all,
and the tests for it also work fine:

        === obj-c++ tests ===


Running target unix/-m64

        === obj-c++ Summary for unix/-m64 ===

# of expected passes        1451
# of expected failures        10
# of unsupported tests        77

Running target unix/-m64/-msave-args

        === obj-c++ Summary for unix/-m64/-msave-args ===

# of expected passes        1451
# of expected failures        10
# of unsupported tests        77

        === obj-c++ Summary ===

# of expected passes        2902
# of expected failures        20
# of unsupported tests        154

Much Regards
Klaus

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


[oi-dev] gcc/gmp assembler integration

2021-02-19 Thread 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
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 :-)

Much Regards
Klaus

P.S. a standalone build of gmp in oi-userland doesn't has this problem,
   because the correct configure tripplets are given to it's configure.
   On SPARC the "make test/check" target has another problem,
   testing libgmpxx, which is another thread to come up.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] brand10 support broken in OI

2021-02-16 Thread Klaus Ziegler - owner of sunfreeware.de

Hi Joshua,

I created an account for myself and also created ticket #13562 and 
assigned it to myself,

hope I can make it, as soon as I have re-installed my x86 build system.

Much Regards
Klaus

On 04.02.21 22:21, Joshua M. Clulow via oi-dev wrote:

On Thu, 4 Feb 2021 at 13:14, Klaus Ziegler - owner of sunfreeware.de
 wrote:

thanks very much for letting us know, is anybody picking up this very
small fix for illumos-gate? it would be really much appreciated.

Anybody can submit a fix for review if it has been tested.  Small
fixes like this are probably a good place to get started with
contribution.

We have a guide to contribution that should help:
https://illumos.org/docs/contributing/

If you need assistance, there are folks on the mailing list and in IRC
that can help!

Cheers.




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


[oi-dev] OpenIndiana 4 sun4u

2021-02-16 Thread Klaus Ziegler - owner of sunfreeware.de

Hi,

as you may know the latest OpenIndiana for SPARC does not run on
sun4u systems, it always panics during the initial CD boot with:

panic[cpu0]/thread=2a100301c80: vmem_xalloc(): size overflow

later on in the dump output one can see:
02a100300f50 zfs:aggsum_init+48 (701348e0, 0, 7b69bbe0, 7b77b3a0, 1, 3)
  %l0-3: 01824000 01814410 02a100300fe8 
01824000
  %l4-7: 030001a82ee0 01834000  
0090

02a100301000 zfs:arc_state_init+1ec (0, 3, 0, 0, 1, 701167b8)
  %l0-3: 70116898 70116800 70116800 
70116800


So for me it looks like the problem is the /kernel/drv/sparcv9/zfs module.
The panic occures in:
usr/src/uts/common/os/vmem.c line: 1085: panic("vmem_xalloc(): size 
overflow");


enough now, about what isn't working, here's the way I got it working:

1. lofiadm mount Gary's iso to /mnt, can be done on x86.
# lofiadm -a `pwd`/OI_2018_02_Text_SPARC.iso
# mount -o ro -F hsfs /dev/lofi/1 /mnt

2. extract the boot_archive to a SPARC, must be a SPARC can't be x86!
# cd /mnt/boot/platform/sun4u
# ls -al boot_archive
-rw-r--r--   1 root root 197425152 Jan.  4 02:16 boot_archive

3. After you copied the archive to the SPARC system mount it using ufs 
filesystem format:

# lofiadm -a `pwd`/boot_archive
# mount -F ufs /dev/lofi/1 /mnt
# cd /mnt/kernel/drv/sparcv9
# rcp/scp  .
# ls -al zfs
-rwxr-xr-x   2 root sys  2229424 Oct 30  2018 zfs
# cd /
# umount /mnt

4. My boot-server is x86, so I copied the modified boot_archive back to 
there.
Setup tftpboot, the same way like s10s_u11wos_24a used to be booted over 
the net.
I used the inetboot binary from v9os, but I also verified that it works 
with the

inetboot from Gary's distribution.
IMPORTANT: rename "boot_archive" to "sparc.miniroot" in the NFS share,
which will be mounted for the initial boot via tftpboot.

5. On the system which you are going to install, insert the 
OI_2018_02_Text_SPARC

CD and boot from the net:
ok boot net -rv
and then you will end up in the installer of Gary's wonderfull distribution.

DRAWBACKS:
1.) you need an empty, but exsiting zpool "rpool" on the system you'll 
going to install.
2.) you have to choose "Install to existing Zpool" - and therfore create 
swap/dump

 devices after the install.
3.) you will not be able to create additional zpools on the system you 
have installed.


I have successfully done this for a SunFire v240 and one Enterprise2 - 
works like
a champ, if you create all your zpools before doing the install. Anyhow 
if you

do have a CDrom in the target system you can always create additional zpools
using the boot fro the v9os CD (be sure to use the correct drives).

P.S. if the system to be installed is a BroadCom Gigabit based one, also 
exchange
   the bge driver in addition to the zfs module - the bge driver 
fro Gray's release

   didn't work for me - I also used the one fro v9os.

Much Regards
Klaus

\\\
(.. )
=o00=(_)=00o=


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] brand10 support broken in OI

2021-02-04 Thread Klaus Ziegler - owner of sunfreeware.de

Hi Peter,

thanks very much for letting us know, is anybody picking up this very
small fix for illumos-gate? it would be really much appreciated.

Much Regards
Klaus

On 01.02.21 23:13, Peter Tribble wrote:


Solaris10 branded zone support in Openindiana is broken likely
since last
year July, because of the following undefined symbol in
s10_brand.so.1:


November, when stack smashing protection was added to userland.

https://www.illumos.org/issues/13274

My initial fix in Tribblix, like here, was to roll back the s10_brand 
pieces to a previous

version. The brand code here isn't changing at all.

This is a potential fix for illumos-gate:

https://github.com/tribblix/tribblix-build/blob/master/illumos/s10-brand-ssp.patch

(I have a successful build with it, but haven't installed it yet to 
test it.)


root@myserver:~# zlogin myzone
[Connected to zone 'myzone' pts/2]
ld.so.1: s10_brand.so.1: fatal: relocation error: file
/.SUNWnative/usr/lib/s10_brand.so.1: symbol __stack_chk_guard:
referenced symbol not found

[Connection to zone 'myzone' pts/2 closed]

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


[oi-dev] brand10 support broken in OI

2021-01-30 Thread Klaus Ziegler - owner of sunfreeware.de

Hi,

Solaris10 branded zone support in Openindiana is broken likely since last
year July, because of the following undefined symbol in s10_brand.so.1:

root@myserver:~# zlogin myzone
[Connected to zone 'myzone' pts/2]
ld.so.1: s10_brand.so.1: fatal: relocation error: file 
/.SUNWnative/usr/lib/s10_brand.so.1: symbol __stack_chk_guard: 
referenced symbol not found


[Connection to zone 'myzone' pts/2 closed]

I tried to upgrade my main OI server several times last year, which 
always ended

by booting into the previous BE and waiting another month for the next try.
Because this is not a really usefull approach, I went into detail 
yesterday and got

the following workaround: mount your previous BE using beadm, copy over
32/64 bit s10_brand.so.1 shared libraries to /usr/lib resp. /usr/lib/64 
and you are

able to use zlogin again.
The zone seems to be running fine directly after "pkg update" but I wasn't
able to log into it using zlogin. To prove this here are the nm outputs 
of both

s10_brand.so.1 libraries:

root@myserver:/usr/lib/64# ls -al s10_brand.so.1*
-rwxr-xr-x   1 root bin   125128 Juni 21  2020 s10_brand.so.1
-rwxr-xr-x   1 root bin   125568 Jan. 29 09:57 
s10_brand.so.1.new_pkg_update

root@myserver:/usr/lib/64# nm s10_brand.so.1 | grep __stack_chk_guard
root@myserver:/usr/lib/64# nm s10_brand.so.1.new_pkg_update | grep 
__stack_chk_guard
[318]   |   0|   0|OBJT |GLOB |0 |UNDEF  
|__stack_chk_guard


Note: this fix is needed for both 32/64 bit libraries, the 32bit one 
re-enables zlogin,
  and the 64bit one, for example enables "uptime" inside the 
zone again.


I'm not new to SunOS/OI, but I never filled a bug against OI.

Regards,
Klaus


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] Shipping the nano editor alongside with vi

2021-01-11 Thread Klaus Ziegler - owner of sunfreeware.de



On 11.01.21 21:59, Bob Friesenhahn wrote:
It would be good if fresh systems would default to fewer quirky 
wiz-bang features yet allow them to easily be enabled for a Linux-like 
experience.


Bob
I absolutely agree and 
vote for it :-)


Much Regards
Klaus Ziegler
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev