date:20160906

Re: [OpenIndiana-discuss] Nobody for whom OI/Hipster Mate on i915/KMS is working fine wants to report?

2016-09-06 Thread Private openbabel

I was testing the DVD mates again and decided to install it but could 
not get the partition manager to work. this is in addition to add to 
panel omission of the volume appelet.


look forward to using this in the future.

Robert



On 06/09/2016 16:23, Мартин Бохниг via openindiana-discuss wrote:

Ok, hi Apostolos,

as said already: A pity that (almost) nobody of all those others for whom it apparently 
works fine took the time to report, while there are always enough individuals interested 
in discussing "code of conduct" and worse pogroms..
Now that the only feedback anybody hears on-list about the i915 backport is "oh, doesn't 
work" it appears as if it is "instable crap", to quote certain well-known geniuses.

Nevertheless thanks for reporting and sorry that you are experiencing problems.

Now, let's nail this issue: Yes, the same pciid 42 was already attched for the 
old ums i915:

https://searchcode.com/codesearch/view/6730577/
alias = pci8086,42  \

And yes, it should also still work with Oracle's newer driver designed for 
Solaris 12 that I backported to OpenSolaris.
Your output below is a good beginning at best, but what's missing:
*Did you still test in 32bit mode, without 32bit i915/drm bins on the 
Hipster/Mate DVD?*

If yes, then it wonders little that you ended with what you call a "black 
screen", because as there is no 32bit compiled version of i915/drm included on the 
DVD, how would it work?

Yesterday I stated already that it *is* possible to build old IA32 bins of 
i915/drm, and they are for download (together with the 64bit bins)  here, as 
said:
http://opensxce.org/intelkms_working_testbins/Intel_DRMxKMS_S12_to_Illumos_backport__RELEASE/01__GLOBAL/01__BINS/TAR/

They would already be part of the Illumos-gate and would by default get built 
for IA32 _and_ x64, if Illumos was anything related to what they claim to be 
(free bird and stuff).
But history took different routes on scary alarming paths.
So, that's why users of outdated hardware still running 32bit kernels have to 
perform the installation manually after the OS is installed in text mode 
following the steps as outlined in   
http://opensxce.org/intelkms_working_testbins/Intel_DRMxKMS_S12_to_Illumos_backport__RELEASE/01__GLOBAL/01__BINS/TAR/INSTALL.txt

So to test them you need at least a USB stick or a growisofs or a 
hdd-installation (because otherwise you have a tough time copying any 32bit 
variant of i915/drm into the boot_archive on wrirte-protected media).

You didn't send /var/log/Xorg.0.log*,
You didn't send syslog
You didn't send any more information, such as where does the "the screen is 
black" event happen.
You did not say if you are now in 64bit mode off DVD, 32bit mode off DVD and if 
64bit mode, why you first said you wanted to run it in 32bit mode.


 From your pciid I could now derive that this is:

{0x8086, 0x42, CHIP_I9XX|CHIP_I965,  "Intel IGDNG_D" }, \

so i965,and in  https://de.wikipedia.org/wiki/Intel-900-Serie


that it appears to be:
P965 [17]
Broadwater 90 nm Q2 2006 ICH8 / ICH8R / ICH8-DH 533 / 800 / 1066 MHz 19 W 8 GB 
RAM DDR2-533/667/800
1.1 keine
Q965 [18]
Broadwater 90 nm Q2 2006 ICH8 / ICH8R / ICH8-DH 533 / 800 / 1066 MHz 19 W 8 GB 
RAM DDR2-533/667/800
1.1 GMA 3000





But as you didn't tell me more about your Netbook (not even its name, only its 
vendor), I can only *guess* if it is 64bit capable: PROBABLY NOT.


So then again tell me how you can expect it to function with the current 
Hipster/Mate KMS LiveDVD, after I explained long and well *that* and *why* it 
does *not* contain IA32 bins for i915/drm?


If you want to test my backport on your vintage hardware, then you need to 
perform the installation in text mode or vesa mode and then take the 32bit bins 
after installation from the link I provided.
Again:  
http://opensxce.org/intelkms_working_testbins/Intel_DRMxKMS_S12_to_Illumos_backport__RELEASE/01__GLOBAL/01__BINS/TAR/




When I try the live DVD on this machine I see a black screen.

Did you read what I wrote yesterday already?
NO 32bit bins of i915/drm on this current iso/DVD.



%martin bochnig



Вторник,  6 сентября 2016, 14:23 UTC от Apostolos Syropoulos 
:

Hello,

As I reported yesterday I have tested the live DVD on a system that has an 
Intel processor.
The system is running a pre-KMS version of Xorg where the i915 is working. Here 
are the details:

node name:  display
Vendor: Intel Corporation
Device: Core Processor Integrated Graphics 
Controller
Sub-Vendor: ASUSTeK Computer Inc.
binding name:   pci8086,42
devfs path: /pci@0,0/display@2
bus addr:   2
pci path:   0,2,0
compatible name:
(pci8086,42.1043.8383.18)(pci8086,42.1043.8383)(pci1043,8383)(pci8086,42.18)(pci8086,42)(pciclass,03)(pciclass,0300)
driver name:

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Alexander Pyhalov




Thomas Wagner писал 06.09.2016 20:53:

Thank you Alex!

Looks good for libgcc_s.so and libstdc++.so.6
Only it makes me wonder, why the elfdump output for none of the
other (non-gcc-runtime-)libs prints "[ LAZY ]" the line right
before the lib.

Interesting is, that even 4.9 has none of the libs with "[ LAZY ]".

As having "lazy load" for libs is there to improve startup latency
for binaries/libs, I would like to ask if someone might find an
example with actually printing "[ LAZY ]".
This can be a completely different binary/project but compiled
with enther the g++ 4.9 or the new g++ 5 version. It should print
"[ LAZY ]" for at least one library. Then I would be completely
happy.

Best Regards,
Thomas



Looking at some real applications look different (g++ 4.9):

$ elfdump -d  /usr/bin/mate-system-monitor

Dynamic Section:  .dynamic
 index  tagvalue
   [0]  POSFLAG_1 0x1 [ LAZY ]
   [1]  NEEDED0x2b7fa libgmodule-2.0.so.0
   [2]  POSFLAG_1 0x1 [ LAZY ]
   [3]  NEEDED0x2b6f5 libpthread.so.1
   [4]  POSFLAG_1 0x1 [ LAZY ]
   [5]  NEEDED0x2b80e libgtop-2.0.so.7
   [6]  POSFLAG_1 0x1 [ LAZY ]
   [7]  NEEDED0x2b81f libwnck-3.so.0
   [8]  POSFLAG_1 0x1 [ LAZY ]
   [9]  NEEDED0x2b82e libgtkmm-3.0.so.1
  [10]  POSFLAG_1 0x1 [ LAZY ]
  [11]  NEEDED0x2b840 libgdkmm-3.0.so.1
  [12]  POSFLAG_1 0x1 [ LAZY ]
  [13]  NEEDED0x2b852 libgtk-3.so.0
  [14]  POSFLAG_1 0x1 [ LAZY ]
  [15]  NEEDED0x2b860 libgdk-3.so.0
  [16]  POSFLAG_1 0x1 [ LAZY ]
  [17]  NEEDED0x2b86e libpangocairo-1.0.so.0
  [18]  POSFLAG_1 0x1 [ LAZY ]
  [19]  NEEDED0x2b885 libpango-1.0.so.0
  [20]  POSFLAG_1 0x1 [ LAZY ]
  [21]  NEEDED0x2b70e libxml2.so.2
  [22]  POSFLAG_1 0x1 [ LAZY ]
  [23]  NEEDED0x2b897 librsvg-2.so.2
  [24]  POSFLAG_1 0x1 [ LAZY ]
  [25]  NEEDED0x2b8a6 libgdk_pixbuf-2.0.so.0
  [26]  POSFLAG_1 0x1 [ LAZY ]
  [27]  NEEDED0x2b8bd libcairo.so.2
  [28]  POSFLAG_1 0x1 [ LAZY ]
  [29]  NEEDED0x2b8cb libgiomm-2.4.so.1
  [30]  POSFLAG_1 0x1 [ LAZY ]
  [31]  NEEDED0x2b8dd libgio-2.0.so.0
  [32]  POSFLAG_1 0x1 [ LAZY ]
  [33]  NEEDED0x2b8ed libglibmm-2.4.so.1
  [34]  POSFLAG_1 0x1 [ LAZY ]
  [35]  NEEDED0x2b900 libgobject-2.0.so.0
  [36]  POSFLAG_1 0x1 [ LAZY ]
  [37]  NEEDED0x2b914 libglib-2.0.so.0
  [38]  POSFLAG_1 0x1 [ LAZY ]
  [39]  NEEDED0x2b925 libsigc-2.0.so.0
  [40]  POSFLAG_1 0x1 [ LAZY ]
  [41]  NEEDED0x2b724 libsocket.so.1
  [42]  POSFLAG_1 0x1 [ LAZY ]
  [43]  NEEDED0x2b74e libstdc++.so.6
  [44]  POSFLAG_1 0x1 [ LAZY ]
  [45]  NEEDED0x2b7a1 libm.so.2
  [46]  POSFLAG_1 0x1 [ LAZY ]
  [47]  NEEDED0x2b7b4 libgcc_s.so.1
  [48]  NEEDED0x2b7ca libc.so.1
  [49]  INIT  0x80cc5b0
  [50]  FINI  0x80cc5e0
  [51]  HASH  0x80566c4
  [52]  STRTAB0x8068050
  [53]  STRSZ 0x2bb36
  [54]  SYMTAB0x805d2d0
  [55]  SYMENT0x10
  [56]  SUNW_SYMTAB   0x805bd90
  [57]  SUNW_SYMSZ0xc2c0
  [58]  SUNW_SORTENT  0x4
  [59]  SUNW_SYMSORT  0x80952d8
  [60]  SUNW_SYMSORTSZ0x2504
  [61]  CHECKSUM  0x83e4
  [62]  VERNEED   0x8093b88
  [63]  VERNEEDNUM0x7
  [64]  PLTRELSZ  0x15b0
  [65]  PLTREL0x11
  [66]  JMPREL0x8097844
  [67]  REL   0x80977dc
  [68]  RELSZ 0x1618
  [69]  RELENT0x8
  [70]  SYMINFO   0x8053b64
  [71]  SYMINSZ   0x2b60
  [72]  SYMINENT  0x4
  [73]  DEBUG 0
  [74]  FLAGS 0   0
  [75]  FLAGS_1   0x100

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Alexander

Some time ago I had an attempt to build illumos with clang.
The main problem is inline assembly, where clang produces a bit different code.


Alex


> On 06 Sep 2016, at 20:51, Aurélien Larcher  wrote:
> 
> On Tue, Sep 6, 2016 at 7:32 PM, Dmitry Kozhinov  wrote:
>> How about LLVM/Clang? I understand that building OI with it sounds
>> unrealistic, but maybe someone doing some research in this direction?
> 
> Clang 3.8.1 is already in the repo.
> 
>> 
>> 
>> ___
>> openindiana-discuss mailing list
>> openindiana-discuss@openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> 
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss


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

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Thomas Wagner

Thank you Alex!

Looks good for libgcc_s.so and libstdc++.so.6
Only it makes me wonder, why the elfdump output for none of the
other (non-gcc-runtime-)libs prints "[ LAZY ]" the line right
before the lib.

Interesting is, that even 4.9 has none of the libs with "[ LAZY ]".

As having "lazy load" for libs is there to improve startup latency
for binaries/libs, I would like to ask if someone might find an 
example with actually printing "[ LAZY ]".
This can be a completely different binary/project but compiled
with enther the g++ 4.9 or the new g++ 5 version. It should print
"[ LAZY ]" for at least one library. Then I would be completely
happy.

Best Regards,
Thomas


On Tue, Sep 06, 2016 at 05:13:10PM +0300, Alexander Pyhalov wrote:
>  On 09/ 6/16 04:57 PM, Thomas Wagner wrote:
[...]
> >
> > ...
> >   [2] somelib.so
> >   [3] [ LAZY ]  <- delayed load/binding, libc.so can bind funcs 
> > earlier then libgcc_s.so
> >   [4] libgcc_s.so
> > ...
> >   [5] someotherlib.so
> >   [6] [ LAZY ]  <- delayed load/binding, libc.so can bind funcs 
> > earlier then libstdc++.so
> >   [7] libstdc++.so
> >
> 
>  Hi.
> 
>  For g++ 5:
> 
>  Dynamic Section:  .dynamic
>   index  tagvalue
> [0]  NEEDED0x2ad   libstdc++.so.6
> [1]  NEEDED0x2ee   libm.so.2
> [2]  NEEDED0x2f8   librt.so.1
> [3]  NEEDED0x303   libgcc_s.so.1
> [4]  NEEDED0x2c8   libc.so.1
> [5]  INIT  0x8051030
> [6]  FINI  0x8051050
> [7]  RUNPATH   0x311   /usr/gcc/5/lib
> [8]  RPATH 0x311   /usr/gcc/5/lib
> [9]  HASH  0x80501c0
>[10]  STRTAB0x8050630
>[11]  STRSZ 0x520
>[12]  SYMTAB0x8050420
>[13]  SYMENT0x10
>[14]  SUNW_SYMTAB   0x80502e0
>[15]  SUNW_SYMSZ0x350
>[16]  SUNW_SORTENT  0x4
>[17]  SUNW_SYMSORT  0x8050be4
>[18]  SUNW_SYMSORTSZ0x50
>[19]  CHECKSUM  0x5bf6
>[20]  VERNEED   0x8050b50
>[21]  VERNEEDNUM0x2
>[22]  FINI_ARRAY0x8061318
>[23]  FINI_ARRAYSZ  0x8
>[24]  INIT_ARRAY0x8061320
>[25]  INIT_ARRAYSZ  0x8
>[26]  PLTRELSZ  0x40
>[27]  PLTREL0x11
>[28]  JMPREL0x8050c64
>[29]  REL   0x8050c34
>[30]  RELSZ 0x70
>[31]  RELENT0x8
>[32]  SYMINFO   0x805013c
>[33]  SYMINSZ   0x84
>[34]  SYMINENT  0x4
>[35]  DEBUG 0
>[36]  FLAGS 0   0
>[37]  FLAGS_1   0   0
>[38]  SUNW_STRPAD   0x200
>[39]  SUNW_LDMACH   0x3eEM_AMD64
>[40]  PLTGOT0x8061078
> [41-51]  NULL  0
> 
> 
>  For g++ 4.9:
>  Dynamic Section:  .dynamic
>   index  tagvalue
> [0]  NEEDED0x2c3   libstdc++.so.6
> [1]  NEEDED0x304   libm.so.2
> [2]  NEEDED0x30e   librt.so.1
> [3]  NEEDED0x319   libgcc_s.so.1
> [4]  NEEDED0x2de   libc.so.1
> [5]  INIT  0x80510c0
> [6]  FINI  0x80510f0
> [7]  HASH  0x80501c0
> [8]  STRTAB0x8050640
> [9]  STRSZ 0x527
>[10]  SYMTAB0x8050430
>[11]  SYMENT0x10
>[12]  SUNW_SYMTAB   0x80502e0
>[13]  SUNW_SYMSZ0x360
>[14]  SUNW_SORTENT  0x4
>[15]  SUNW_SYMSORT  0x8050bfc
>[16]  SUNW_SYMSORTSZ0x50
>[17]  CHECKSUM  0xaddb
>[18]  VERNEED   0x8050b68
>[19]  VERNEEDNUM0x2
>[20]  PLTRELSZ  0x40
>[21]  PLTREL0x11
>[22]  JMPREL0x8050c7c
>[23]  REL   0x8050c4c
>[24]  RELSZ 0x70
>[25]  RELENT0x8
>[26]  SYMINFO   0x805013c
>[27]  SYMINSZ   0x84
>[28]  SYMINENT  0x4
>[29]  DEBUG 0
>[30]  FLAGS 0   0
>[31]  FLAGS_1   0   0
>[32]  SUNW_STRPAD   0x200
>[33]  SUNW_LDMACH   0x3eEM_AMD64
>[34]  PLTGOT0x806111c
> [35-45]  NULL  0
> 
>  I don't see any specific patch for -zinterpose...
> 
> 
>  -- 
>  Best regards,
>  Alexander Pyhalov,
>  system administrator of Southern Federal

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Aurélien Larcher

On Tue, Sep 6, 2016 at 7:32 PM, Dmitry Kozhinov  wrote:
> How about LLVM/Clang? I understand that building OI with it sounds
> unrealistic, but maybe someone doing some research in this direction?

Clang 3.8.1 is already in the repo.

>
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss



-- 
---
Praise the Caffeine embeddings

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

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Dmitry Kozhinov

How about LLVM/Clang? I understand that building OI with it sounds 
unrealistic, but maybe someone doing some research in this direction?


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

Re: [OpenIndiana-discuss] Nobody for whom OI/Hipster Mate on i915/KMS is working fine wants to report?

2016-09-06 Thread Мартин Бохниг via openindiana-discuss

Ok, hi Apostolos,

as said already: A pity that (almost) nobody of all those others for whom it 
apparently works fine took the time to report, while there are always enough 
individuals interested in discussing "code of conduct" and worse pogroms..
Now that the only feedback anybody hears on-list about the i915 backport is 
"oh, doesn't work" it appears as if it is "instable crap", to quote certain 
well-known geniuses.

Nevertheless thanks for reporting and sorry that you are experiencing problems.

Now, let's nail this issue: Yes, the same pciid 42 was already attched for the 
old ums i915:

https://searchcode.com/codesearch/view/6730577/  
alias = pci8086,42  \

And yes, it should also still work with Oracle's newer driver designed for 
Solaris 12 that I backported to OpenSolaris.
Your output below is a good beginning at best, but what's missing: 
*Did you still test in 32bit mode, without 32bit i915/drm bins on the 
Hipster/Mate DVD?*

If yes, then it wonders little that you ended with what you call a "black 
screen", because as there is no 32bit compiled version of i915/drm included on 
the DVD, how would it work?

Yesterday I stated already that it *is* possible to build old IA32 bins of 
i915/drm, and they are for download (together with the 64bit bins)  here, as 
said:
http://opensxce.org/intelkms_working_testbins/Intel_DRMxKMS_S12_to_Illumos_backport__RELEASE/01__GLOBAL/01__BINS/TAR/
  

They would already be part of the Illumos-gate and would by default get built 
for IA32 _and_ x64, if Illumos was anything related to what they claim to be 
(free bird and stuff).
But history took different routes on scary alarming paths.
So, that's why users of outdated hardware still running 32bit kernels have to 
perform the installation manually after the OS is installed in text mode 
following the steps as outlined in   
http://opensxce.org/intelkms_working_testbins/Intel_DRMxKMS_S12_to_Illumos_backport__RELEASE/01__GLOBAL/01__BINS/TAR/INSTALL.txt
  

So to test them you need at least a USB stick or a growisofs or a 
hdd-installation (because otherwise you have a tough time copying any 32bit 
variant of i915/drm into the boot_archive on wrirte-protected media).

You didn't send /var/log/Xorg.0.log*, 
You didn't send syslog
You didn't send any more information, such as where does the "the screen is 
black" event happen.
You did not say if you are now in 64bit mode off DVD, 32bit mode off DVD and if 
64bit mode, why you first said you wanted to run it in 32bit mode.


From your pciid I could now derive that this is:

{0x8086, 0x42, CHIP_I9XX|CHIP_I965,  "Intel IGDNG_D" }, \

so i965,and in  https://de.wikipedia.org/wiki/Intel-900-Serie  


that it appears to be:
P965 [17]
Broadwater 90 nm Q2 2006 ICH8 / ICH8R / ICH8-DH 533 / 800 / 1066 MHz 19 W 8 GB 
RAM DDR2-533/667/800
1.1 keine
Q965 [18]
Broadwater 90 nm Q2 2006 ICH8 / ICH8R / ICH8-DH 533 / 800 / 1066 MHz 19 W 8 GB 
RAM DDR2-533/667/800
1.1 GMA 3000





But as you didn't tell me more about your Netbook (not even its name, only its 
vendor), I can only *guess* if it is 64bit capable: PROBABLY NOT.


So then again tell me how you can expect it to function with the current 
Hipster/Mate KMS LiveDVD, after I explained long and well *that* and *why* it 
does *not* contain IA32 bins for i915/drm?


If you want to test my backport on your vintage hardware, then you need to 
perform the installation in text mode or vesa mode and then take the 32bit bins 
after installation from the link I provided.
Again:  
http://opensxce.org/intelkms_working_testbins/Intel_DRMxKMS_S12_to_Illumos_backport__RELEASE/01__GLOBAL/01__BINS/TAR/
  



> When I try the live DVD on this machine I see a black screen.

Did you read what I wrote yesterday already?
NO 32bit bins of i915/drm on this current iso/DVD.



%martin bochnig


>Вторник,  6 сентября 2016, 14:23 UTC от Apostolos Syropoulos 
>:
>
>Hello,
>
>As I reported yesterday I have tested the live DVD on a system that has an 
>Intel processor.
>The system is running a pre-KMS version of Xorg where the i915 is working. 
>Here are the details:
>
>node name:  display
>Vendor: Intel Corporation
>Device: Core Processor Integrated Graphics 
>Controller
>Sub-Vendor: ASUSTeK Computer Inc.
>binding name:   pci8086,42
>devfs path: /pci@0,0/display@2
>bus addr:   2
>pci path:   0,2,0
>compatible name:
>(pci8086,42.1043.8383.18)(pci8086,42.1043.8383)(pci1043,8383)(pci8086,42.18)(pci8086,42)(pciclass,03)(pciclass,0300)
>driver name:i915
>instance:   0
>driver state:   Attached
>ddi-no-autodetach:  1
>fm-errcb-capable:   TRUE
>fm-ereport-capable: TRUE
>primary-controller:

Re: [OpenIndiana-discuss] Nobody for whom OI/Hipster Mate on i915/KMS is working fine wants to report?

2016-09-06 Thread Apostolos Syropoulos via openindiana-discuss

Hello,

As I reported yesterday I have tested the live DVD on a system that has an 
Intel processor.
The system is running a pre-KMS version of Xorg where the i915 is working. Here 
are the details:

node name:  display
Vendor: Intel Corporation
Device: Core Processor Integrated Graphics 
Controller
Sub-Vendor: ASUSTeK Computer Inc.
binding name:   pci8086,42
devfs path: /pci@0,0/display@2
bus addr:   2
pci path:   0,2,0
compatible name:
(pci8086,42.1043.8383.18)(pci8086,42.1043.8383)(pci1043,8383)(pci8086,42.18)(pci8086,42)(pciclass,03)(pciclass,0300)
driver name:i915
instance:   0
driver state:   Attached
ddi-no-autodetach:  1
fm-errcb-capable:   TRUE
fm-ereport-capable: TRUE
primary-controller: 1
ddi-kernel-ioctl:   TRUE
pci-msi-capid-pointer:  90
acpi-namespace: _SB_.PCI0.GFX0
assigned-addresses: 83001010
reg:1000
compatible: pci8086,42.1043.8383.18
model:  VGA compatible controller
power-consumption:  1
fast-back-to-back:  TRUE
devsel-speed:   0
interrupts: 1
max-latency:0
min-grant:  0
subsystem-vendor-id:1043
subsystem-id:   8383
device_type:display
unit-address:   2
class-code: 3
revision-id:18
vendor-id:  8086
device-id:  42

 

When I try the live DVD on this machine I see a black screen.
In the file driver_aliases that Martin supplied ther was the
following entry:


i915 "pci8086,42"

I guess but I am not sure that the graphics hardware should work.
Is there anything I can do to help resolve this problem?

A.S.

--
Apostolos Syropoulos
Xanthi, Greece

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

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Alexander Pyhalov


On 09/ 6/16 04:57 PM, Thomas Wagner wrote:

Hi Aurelien,

it would be very cool if someone could send me / the list the output
of "elfdump -d" on a compiled binary with C++ code. If that is not
available, then regular C-code is okay too. e.g. gcc -o hello hello.c
I have no test system at hand (have only older hipster on disk).

What I would appreciated to see would be a configuration that has
"[ LAZY ]"-load removed (only) for gcc runtime libs.

Excample "good":

...
  [2] somelib.so
  [3] libgcc_s.so
...
  [5] someotherlib.so
  [6] libstdc++.so


Excample "bad":

...
  [2] somelib.so
  [3] [ LAZY ]  <- delayed load/binding, libc.so can bind funcs earlier 
then libgcc_s.so
  [4] libgcc_s.so
...
  [5] someotherlib.so
  [6] [ LAZY ]  <- delayed load/binding, libc.so can bind funcs earlier 
then libstdc++.so
  [7] libstdc++.so



Hi.

For g++ 5:

Dynamic Section:  .dynamic
 index  tagvalue
   [0]  NEEDED0x2ad   libstdc++.so.6
   [1]  NEEDED0x2ee   libm.so.2
   [2]  NEEDED0x2f8   librt.so.1
   [3]  NEEDED0x303   libgcc_s.so.1
   [4]  NEEDED0x2c8   libc.so.1
   [5]  INIT  0x8051030
   [6]  FINI  0x8051050
   [7]  RUNPATH   0x311   /usr/gcc/5/lib
   [8]  RPATH 0x311   /usr/gcc/5/lib
   [9]  HASH  0x80501c0
  [10]  STRTAB0x8050630
  [11]  STRSZ 0x520
  [12]  SYMTAB0x8050420
  [13]  SYMENT0x10
  [14]  SUNW_SYMTAB   0x80502e0
  [15]  SUNW_SYMSZ0x350
  [16]  SUNW_SORTENT  0x4
  [17]  SUNW_SYMSORT  0x8050be4
  [18]  SUNW_SYMSORTSZ0x50
  [19]  CHECKSUM  0x5bf6
  [20]  VERNEED   0x8050b50
  [21]  VERNEEDNUM0x2
  [22]  FINI_ARRAY0x8061318
  [23]  FINI_ARRAYSZ  0x8
  [24]  INIT_ARRAY0x8061320
  [25]  INIT_ARRAYSZ  0x8
  [26]  PLTRELSZ  0x40
  [27]  PLTREL0x11
  [28]  JMPREL0x8050c64
  [29]  REL   0x8050c34
  [30]  RELSZ 0x70
  [31]  RELENT0x8
  [32]  SYMINFO   0x805013c
  [33]  SYMINSZ   0x84
  [34]  SYMINENT  0x4
  [35]  DEBUG 0
  [36]  FLAGS 0   0
  [37]  FLAGS_1   0   0
  [38]  SUNW_STRPAD   0x200
  [39]  SUNW_LDMACH   0x3eEM_AMD64
  [40]  PLTGOT0x8061078
   [41-51]  NULL  0


For g++ 4.9:
Dynamic Section:  .dynamic
 index  tagvalue
   [0]  NEEDED0x2c3   libstdc++.so.6
   [1]  NEEDED0x304   libm.so.2
   [2]  NEEDED0x30e   librt.so.1
   [3]  NEEDED0x319   libgcc_s.so.1
   [4]  NEEDED0x2de   libc.so.1
   [5]  INIT  0x80510c0
   [6]  FINI  0x80510f0
   [7]  HASH  0x80501c0
   [8]  STRTAB0x8050640
   [9]  STRSZ 0x527
  [10]  SYMTAB0x8050430
  [11]  SYMENT0x10
  [12]  SUNW_SYMTAB   0x80502e0
  [13]  SUNW_SYMSZ0x360
  [14]  SUNW_SORTENT  0x4
  [15]  SUNW_SYMSORT  0x8050bfc
  [16]  SUNW_SYMSORTSZ0x50
  [17]  CHECKSUM  0xaddb
  [18]  VERNEED   0x8050b68
  [19]  VERNEEDNUM0x2
  [20]  PLTRELSZ  0x40
  [21]  PLTREL0x11
  [22]  JMPREL0x8050c7c
  [23]  REL   0x8050c4c
  [24]  RELSZ 0x70
  [25]  RELENT0x8
  [26]  SYMINFO   0x805013c
  [27]  SYMINSZ   0x84
  [28]  SYMINENT  0x4
  [29]  DEBUG 0
  [30]  FLAGS 0   0
  [31]  FLAGS_1   0   0
  [32]  SUNW_STRPAD   0x200
  [33]  SUNW_LDMACH   0x3eEM_AMD64
  [34]  PLTGOT0x806111c
   [35-45]  NULL  0

I don't see any specific patch for -zinterpose...


--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

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

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Thomas Wagner

Hi Aurelien,

it would be very cool if someone could send me / the list the output
of "elfdump -d" on a compiled binary with C++ code. If that is not
available, then regular C-code is okay too. e.g. gcc -o hello hello.c
I have no test system at hand (have only older hipster on disk).

What I would appreciated to see would be a configuration that has
"[ LAZY ]"-load removed (only) for gcc runtime libs.

Excample "good":

...
 [2] somelib.so
 [3] libgcc_s.so
...
 [5] someotherlib.so
 [6] libstdc++.so

Excample "bad":

...
 [2] somelib.so
 [3] [ LAZY ]  <- delayed load/binding, libc.so can bind funcs earlier 
then libgcc_s.so
 [4] libgcc_s.so
...
 [5] someotherlib.so
 [6] [ LAZY ]  <- delayed load/binding, libc.so can bind funcs earlier 
then libstdc++.so
 [7] libstdc++.so

This removed "LAZY"-load avoids situation where uncatched C++ exceptions
are falling through into into library /usr/lib/libc.so which normally can't
handle them, so binary core dumps.
Prominent example is "filezilla".

In SFEgcc we set "-zinterpose" to have the resulting binaries link (only) the
gcc runtime without the LAZY flag.

Thanks much!
Thomas

On Tue, Sep 06, 2016 at 03:34:21PM +0200, Aur??lien Larcher wrote:
> Hello,
> I wrote a short post about it:
> 
> https://www.openindiana.org/2016/09/06/gcc-5-4-now-available-as-testing-compiler/
> 
> Thanks go to Rich Lowe for his fixes to the linker and to Alexander
> for patches and thorough testing.
> 
> Please comment if you think about additional information which should
> be provided.
> Best regards,
> 
> Aurelien
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
> 

-- 
-- 
Thomas Wagner

Service rund um UNIX(TM), Wagner Network Services, Thomas Wagner
Solaris(TM), Linux(TM)Eschenweg 21, 89174 Altheim, Germany
Novell(TM), Windows(TM)   TEL: +49-731-9807799, FAX: +49-731-9807711
Telekommunikation, LAN,   MOBILE/CELL: +49-171-6135989
Internet-Service, Elektronik  EMAIL: wag...@wagner-net.com

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

[OpenIndiana-discuss] GCC 5.4 added to the repository

2016-09-06 Thread Aurélien Larcher

Hello,
I wrote a short post about it:

https://www.openindiana.org/2016/09/06/gcc-5-4-now-available-as-testing-compiler/

Thanks go to Rich Lowe for his fixes to the linker and to Alexander
for patches and thorough testing.

Please comment if you think about additional information which should
be provided.
Best regards,

Aurelien

-- 
---
Praise the Caffeine embeddings

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

Re: [OpenIndiana-discuss] Nobody for whom OI/Hipster Mate on i915/KMS is working fine wants to report?

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

Re: [OpenIndiana-discuss] Nobody for whom OI/Hipster Mate on i915/KMS is working fine wants to report?

Re: [OpenIndiana-discuss] Nobody for whom OI/Hipster Mate on i915/KMS is working fine wants to report?

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

Re: [OpenIndiana-discuss] GCC 5.4 added to the repository

[OpenIndiana-discuss] GCC 5.4 added to the repository

11 matches

Site Navigation

Mail list logo

Footer information