cwbe coordinatez:
101
63540
63542
2109677
907144

ABSOLUT
KYBERIA
permissions
you: r,
system: public
net: yes

neurons

stats|by_visit|by_K
source
tiamat
K|my_K|given_K
last
commanders
polls

total descendants::
total children::4
1 ❤️


show[ 2 | 3] flat


zyx0
pejko0
e1m10
pyxel0
Joker0
Ruza0
..............0
Bruta0
uz.nebudem.t...0
nudzo0
schrapnel0

Solaris 64-bit


Portovanie prevazne GNU softu. Mozno dake benchmarqs.

portaris


Solarisovy port Gentoo portage - sprava balikov.




000001010006354000063542021096770090714401003181
nudzo
 nudzo      14.07.2004 - 20:04:05 , level: 1, UP   NEW
Uf... libiconv a gettext riadna haluz... kruhove zavislosti... libiconv potrebuje libky z gettext a gettext zase je rad ked ma libiconv... blee...
postup: 1. gettext 2. libiconv 3. gettext
by default sa tiez pouzije libiconv z libc solarisu, ale da sa finta
export LD_PRELOAD=/usr/local/lib/sparcv9/libiconv_plug.so
Samba ma celkom problem bez tychto dvoch veci... zvlast, ked sa na nu xu dostat WinXP...

000001010006354000063542021096770090714400915545
nudzo
 nudzo      08.06.2004 - 17:38:24 , level: 1, UP   NEW
Pre tych, co xu experimentovat:
napr. aterm (ten bezi koser 64-bit) v jeho zdrojakoch scriptik


#!/bin/bash

export PATH=/usr/ccs/bin:$PATH
export CC=/usr/local/bin/gcc
export CXX=/usr/local/bin/g++
#export LD=/usr/ccs/bin/ld
export CFLAGS="-I/usr/local/include -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 -m64 -fprefetch-loop-arrays"
export CPPFLAGS=$CFLAGS
export CXXFLAGS=$CFLAGS
export LDFLAGS="-m64 -L/usr/local/lib -Wl,-R -Wl,/usr/local/lib:/usr/local/lib/sparcv9"

./configure --enable-utmp --enable-background-image --enable-transparency --enable-fading --enable-graphics --enable-next-scroll --enable-ttygid --with-x --with-xpm


Samozrejme vsetky lib. co vec potrebuje musia niekde byt 64-bit... 32b sa so 64b nezlinkuje... preto tie rpath v LDFLAGS... a vec potom vyzera takto...


inu@sun inu $ ldd /usr/local/bin/aterm
libSM.so.6 => /usr/lib/64/libSM.so.6
libICE.so.6 => /usr/lib/64/libICE.so.6
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libnsl.so.1 => /usr/lib/64/libnsl.so.1
libXpm.so.4 => /usr/lib/64/libXpm.so.4
libX11.so.4 => /usr/lib/64/libX11.so.4
libc.so.1 => /usr/lib/64/libc.so.1
libdl.so.1 => /usr/lib/64/libdl.so.1
libmp.so.2 => /usr/lib/64/libmp.so.2
libXext.so.0 => /usr/openwin/lib/sparcv9/libXext.so.0
/usr/platform/SUNW,Sun-Fire-V250/lib/sparcv9/libc_psr.so.1

alebo gawk

inu@sun inu $ ldd /usr/local/bin/gawk
libiconv.so.2 => /usr/local/lib/sparcv9/libiconv.so.2
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libnsl.so.1 => /usr/lib/64/libnsl.so.1
libdl.so.1 => /usr/lib/64/libdl.so.1
libm.so.1 => /usr/lib/64/libm.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libgcc_s.so.1 => /usr/local/lib/sparcv9/libgcc_s.so.1
libmp.so.2 => /usr/lib/64/libmp.so.2
/usr/platform/SUNW,Sun-Fire-V250/lib/sparcv9/libc_psr.so.1


A tu je linka, ze ako to SUN vidi... http://docs.sun.com/db/doc/806-6543

000001010006354000063542021096770090714400908221
maniac
 maniac      07.06.2004 - 08:28:24 , level: 1, UP   NEW
ako to myslis ze sun sa nehrnie do 64 bitov? ja som bol v tom ze veci co bezia na 64bitovych sparkoch su vacsinou 64bitove..

00000101000635400006354202109677009071440090822100911347
nudzo
 nudzo      07.06.2004 - 19:42:06 , level: 2, UP   NEW
No to je pravda, ze procesory su 64-bit... ale kolko aplikacii bezi 64-bit... :-) Akoze core systemu je aj 32, aj 64... Gnome sice je zakladny desktop, ale iba par zakladnych libiek je portnutych na 64-bit... takze tak...

0000010100063540000635420210967700907144009082210091134700911773
maniac
 maniac      07.06.2004 - 22:20:34 , level: 3, UP   NEW
neni to nahodou vecou kompileru ako tie libky skompiluje?

000001010006354000063542021096770090714400908221009113470091177300915482
nudzo
 nudzo      08.06.2004 - 17:21:17 , level: 4, UP   NEW
Je vecou kompileru, tada skor toho, kto kompiluje... pre gcc parameter -m64 a pre sun-cc -Xarch=v9... Cely solaris 9 co mam na SUNe je vo verzii 32-bit aj 64-bit... 64-bit neni jedine Gnome... ostatne vsetko je aj-aj, takze len zalezi aky parameter sa pri kompilacii pouzije... je tu vsak jeden problem... a sice C-ckovy typ pointer ma size 64 namiesto 32 a taktiez long neni v tomto pripade 32bit ale 64bit... a ked kod def. predpoklada nejaku velkost, tak to v strukturach robi bordel zakonite... a veci zvycajne koncia SIGSEGV... No a na to ma SUN taky tool, ze lint, ktory by v kode mal zistit problemy tohto typu...

00000101000635400006354202109677009071440090822100911347009117730091548200915758
uz.nebudem.tolko.fetovat
 uz.nebudem.tolko.fetovat      08.06.2004 - 18:28:26 , level: 5, UP   NEW
poznam z toho, ked som sa hral s filesystemom unixu v7/v6, a nemohol som pouzit povodne hlavicky, lebo tie boli robene pre 16 bitove pdpcka ;)))

000001010006354000063542021096770090714400908221009113470091177300914119
uz.nebudem.tolko.fetovat
 uz.nebudem.tolko.fetovat      08.06.2004 - 13:05:41 , level: 4, UP   NEW
tiez som myslel... sak to sa preipse to, co je v kerneli, v cc a v libc zavisle na platforme a ostatny ceckovy kod sa len prekompiluje

000001010006354000063542021096770090714400907255
nudzo
 nudzo      06.06.2004 - 21:16:03 , level: 1, UP   NEW
Zatial prve pokusy... po tyzdni spekulovania vysvitlo, ze ani SUN sa moc zatial nehrnie do tych 64-bitov a ani to nebude vsetko take ez ako sa na prvy pohlad zdalo. Kazdopadne zatial sa mi podarilo zriesit 64-bit sambu a postgres... Mam paralelne 32-bit aj 64-bit postgres na jednej masinke (SunFire V250 2xUltraSparc3 1.4GHz) tak asi skusim daky benchmarq... ci to vobec ma daky vyznam riesit... :-)
Z toho co som zatial na 64-bit skusil, jedine fluxbox 0.9.9 - ee... padalo to...
K sambe a postgresu boli aj dake libky - readline, iconv, ldap, zlib - tie vyzeraju byt v poho..