nekoware freeware coexistence

IRIX/Nekoware development, porting and related topics.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
zone
Posts: 106
Joined: Mon Nov 15, 2004 4:43 am
Location: /usr/people/zone

nekoware freeware coexistence

Unread postby zone » Sat Dec 11, 2004 8:48 am

Have question on nekoware.

Before I goin to mess my systems would like to know do I can use fw and neko distributions in coexistence on single system... eg: for instance, if I have fw_libjpeg already installed and some neko package installs neko_libjpeg
, which one will be used by system. Assuming that there is fix_path fw or something as *fix_neko* seted as system variable.

User avatar
donny
Posts: 130
Joined: Thu Mar 25, 2004 6:42 am
Location: Jacksonville, FL
Contact:

Unread postby donny » Sat Dec 11, 2004 10:18 am

In my experience, Nekoware and SGI Freeware work just fine together. I have the entire May '04 Freeware installed, and most of the neko beta packages. No probs at all on any of my boxes.
There is no spoon

hamei
Posts: 9886
Joined: Tue Feb 24, 2004 5:10 pm

Unread postby hamei » Sat Dec 11, 2004 10:31 am

donny wrote:In my experience, Nekoware and SGI Freeware work just fine together. I have the entire May '04 Freeware installed, and most of the neko beta packages. No probs at all on any of my boxes.


True. But what I'd really like to do is ditch the duplicates. I ain't got all that much disk space, and two copies each of a hunnerd and thirty-five shared libraries seems ... redundant ? Suggestions, anyone ? Links from /nekoware to /freeware should work ?

zone
Posts: 106
Joined: Mon Nov 15, 2004 4:43 am
Location: /usr/people/zone

Unread postby zone » Sat Dec 11, 2004 10:53 am

hamei wrote:
True. But what I'd really like to do is ditch the duplicates. I ain't got all that much disk space, and two copies each of a hunnerd and thirty-five shared libraries seems ... redundant ? Suggestions, anyone ? Links from /nekoware to /freeware should work ?


Hmm, I wouldn't care that much on disk space as nekoware seems to be bulit for 6.5.20+ (or in lower case 6.5.15 if I understand it correct), so most if not all of my systems which are running this range of IRIX streams are having decent system drives, 36GB-73GB, so Im not concerned about *drive waste* but potentional *collateral issues*.

Also If I could ask nekoware contributers is there way to have neko_fw_packages, means nekoware with refers for nonincluded stuff to fw (/usr/freeware/bin)...or neko developers/contributers are goin to assure me that *We're way to go*, so that I can eventualy ditch fw and switch to nekoware since fw at sgi is loosing momentum despite of all these great girls'n'guys at sgi who workin' hard to contribute and maintain freeware.sgi.com...
No Im not goin to ditch fw as long as fw is there, at least updated once per year but nekoware is prolific, live and kicking with ability to get in touch in via nekoforums with contributors etc...

User avatar
dexter1
Moderator
Moderator
Posts: 2062
Joined: Thu Feb 20, 2003 7:57 am
Location: Voorburg, The Netherlands
Contact:

Unread postby dexter1 » Sat Dec 11, 2004 1:37 pm

Because i had a word with Confused Hacker (freeware maintainer) and WhizzMan on #nekochan about this, and am contributor for Nekoware, let me say a few words in this. (make that a lot :) )

Initially Nekoware was forged because of dissatisfaction with the current freeware release rate, staleness of packages and general uncertainty of SGI maintaining/supporting IRIX at all. Converging nekoware to a stable standard wasn't easy and we had lots of hefty discussions about this. We are now at a point where the amount of Nekoware is so large that we reached a useable software environment. Lots of people already run Nekoware solely on their boxes.

Confused Hacker is a man with little time and the next freeware probably won't be a surprise edition of hundreds of new packages. But he made it clear that there is real and genuine interest in the SGI echelon to keep freeware alive and well.

He is most interested in our way of making all these cool patches and software builds and packages. I've explained on his request our filosophy and package structure/creation, because these two systems are different in details, but also in concept. For instance our choice to go with -mips4 is the opposite of freeware which is -mips3. But -mips4 is the only way to churn out the most speed increase which, unfortunately, is very necessary for those (euphemism) less-than-optimised opensource code we all got to know so well in these past few years. He is now getting to know our way of working and i'll expect him to bombard me with a lot of questions in this matter.

That is also why we chose to start a separate and clean package environment and directory to coexist with freeware. Not to surpass freeware but to provide a cutting-edge fast environment for our mips4 machines, while maintaining exising built stuff, which runs fine. (CUPS!)

I agree with some of the criticism that having two software environment "flavors" kinda dilutes the effort. But please, also understand this from a historic point-of-view, written in the second paragraph.

I also don't know what the future will bring us. Maybe Nekoware and Freeware merge, maybe not. time will tell.

Linking libs from freeware to nekoware and vice-versa could very well work. I tried for instance Diego's GeneratriX and while he had only freeware prereqs, i 'set rulesoverride on' installed it and ran fine with nekoware libs. But bear in mind that we have no way of testing all those interdependencies, API foulups and other ld.so horrors. Let alone time :( So you're (for now) on your own when you want to do that.

I hope this makes things clear. To summarize:
1) yes you can run freeware and nekoware separately
2) freeware is -mips3, nekoware is -mips4. Crosslinking may work, but prepare to either suffer code slowdown or a blunt refusal to work ("This machine can not execute MIPSIV instructions...")

User avatar
nekonoko
Site Admin
Site Admin
Posts: 8001
Joined: Thu Jan 23, 2003 2:31 am
Location: Pleasanton, California
Contact:

Unread postby nekonoko » Sat Dec 11, 2004 5:23 pm

Another thing to consider is this quote from http://freeware.sgi.com/faq.html#Q3.7 :

If you distribute your own packages please do not install them under /usr/freeware, or give them names beginning with "fw_". If you do it's likely to cause trouble if/when we eventually add it to our distribution.


/usr/freeware belongs to SGI and we really don't want to step on their toes while SGI Freeware still has a heartbeat.

What you can do is port software to IRIX and send any patches to the official maintainers (and to us).


We do both - the patches are available in every Nekoware tardist which SGI can use if they choose. We obviously can't (at least I've never been asked to) contribute directly to SGI Freeware due to the security concerns outlined in Q3.7 above. I do keep in touch with the Freeware maintainer though and there's been some talk that things may open up a bit in the future.
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.

User avatar
GeneratriX
Posts: 4226
Joined: Tue Oct 21, 2003 2:07 am
Location: Rosario / Santa Fe / República Argentina

FreeWares

Unread postby GeneratriX » Sat Dec 11, 2004 6:23 pm

dexter1 wrote:Linking libs from freeware to nekoware and vice-versa could very well work. I tried for instance Diego's GeneratriX and while he had only freeware prereqs, i 'set rulesoverride on' installed it and ran fine with nekoware libs.


Dexter1:

the next version (V0.99), of GeneratriX (I like your upper case "X"!!! :)), there'll be linked alterantively to:

1) A GeneratriX internally fixed version of the SharedObjects.

2) Nekochan.Net FreeWare version of the SharedObjects.

3) SGI FreeWare version of the SharedObjects.

This will give to the End-User, the power to experiment with the software under serveral environments or prereqs, and then we'll have a more powerful Beta-Testing too! ;)

My hopes are; make wider the range of availability; increase the compatability on every box with IRIX; test my packages under every available circumstance.

Oh!; and BTW:

My votes are so far for a merged/homogeneous environment, between SGI FreeWare / NekochanNet FreeWare!

But if it's not happens; I'll be very happy anyway!
Thanks to all, as an SGI's User, for the first quality work!
Cheers! ;)

hamei
Posts: 9886
Joined: Tue Feb 24, 2004 5:10 pm

Unread postby hamei » Sat Dec 11, 2004 7:30 pm

dexter1 wrote: I agree with some of the criticism that having two software environment "flavors" kinda dilutes the effort. But please, also understand this from a historic point-of-view, written in the second paragraph.


No criticism intended but when I'm dumping Netscape and other apps just to make room, those duplicates look really juicy to the axe ... (Java 1.1.8 looks like a good candidate, too, but something uses it, I can't remember what ... )

So .... are the libraries dependent on path order like on Intel, so if I first switched nekoware and freeware's order, I'd be getting neko libs rather than freeware libs ? Then could remove freeware directories from the path for further tests without upsetting the applecart ?

User avatar
dexter1
Moderator
Moderator
Posts: 2062
Joined: Thu Feb 20, 2003 7:57 am
Location: Voorburg, The Netherlands
Contact:

Unread postby dexter1 » Sun Dec 12, 2004 5:05 am

hamei wrote:So .... are the libraries dependent on path order like on Intel, so if I first switched nekoware and freeware's order, I'd be getting neko libs rather than freeware libs ? Then could remove freeware directories from the path for further tests without upsetting the applecart ?


Uhm, not really. There are several factors:
1) SGI versioning. SGI keeps it's version info in the ELF header of the .so library, while linux works with absolute file names and version numbering behind the .so suffix
I'm 100% not sure how it actually works, but a man ld or man dso works miracles :)
2) LD_LIBRARY_PATH. The order of directories is important.
3) RLD_LIST. If set with a specific .so lib, it will precede any shared library symbol resolving!
4) Hardcoded link paths in the executable. If programs are linked with -Wl,-rpath -Wl,/usr/nekoware/lib, it will resolve synbols in that directory first. Not something you generally want, but sometimes necessary for programs which you want to run as root.
Last edited by dexter1 on Sun Dec 12, 2004 5:53 am, edited 1 time in total.

hamei
Posts: 9886
Joined: Tue Feb 24, 2004 5:10 pm

Unread postby hamei » Sun Dec 12, 2004 5:49 am

dexter1 wrote: Uhm, not really. There are several factors:
1) SGI versioning. SGI keeps it's version info in the ELF header of the .so library, while linux works with absolute file names and version numbering behind the .so suffix
If you want a specific version, you can do it either way:
The SGI way: set the version dependency to a specific SGI lib version in the linking stage:
The linux way: link to a specific filename/version:


Yuck. Sigh. Thanks .... static builds ! static builds ! screw this unshared library *&%$ !!

zone
Posts: 106
Joined: Mon Nov 15, 2004 4:43 am
Location: /usr/people/zone

Unread postby zone » Sun Dec 12, 2004 10:10 am

dexter1, thanks very much on your insightfull, *in depth* answer.


Return to “SGI: Development”

Who is online

Users browsing this forum: No registered users and 2 guests