On MIPS processor I believe PIC is the default and only way to build shared libs (same on PowerPC).
SGI: Development
Nekoware-current - Page 5
Better be safe than sorry, and having the latest version is always good. And the current version is not build with specificaly having -fPIC defined, and does not work with mod_ssl.
(Even though the cc manual indeed states
)
(Even though the cc manual indeed states
Code: Select all
-KPIC Generates position-independent code (PIC). This is the
default and is needed for programs linking with dynamic
shared libraries. If you do not want to generate PIC,
specify -non_shared on the command line.
Shall I describe it to you? Or do you want me to get you a box?
neko_openssl-0.9.7j is the latest version; I'm guessing you're referring to 0.9.8? That version would break most of Nekoware from my experimentation and there's no reason to go there with 0.9.7 still being actively supported.
As for -fPIC - you've totally lost me there - I don't understand how we can successfully link against neko_openssl in the huge amount of software we've compiled for Nekoware and suddenly we need some esoteric flag for mod_ssl? WTF?
And if you link against the system openssl I'm going to kick it right back at ya - that's a no-no for Nekoware
As for -fPIC - you've totally lost me there - I don't understand how we can successfully link against neko_openssl in the huge amount of software we've compiled for Nekoware and suddenly we need some esoteric flag for mod_ssl? WTF?
And if you link against the system openssl I'm going to kick it right back at ya - that's a no-no for Nekoware
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
then I suggest you remove neko_apache, which has been there for ages, since that's linked against irix openssl.
From the mod_ssl INSTALL notes:
And from joerg's apache relnotes:
From the mod_ssl INSTALL notes:
Code: Select all
OpenSSL has problems under DSO situations on some
platforms. OpenSSL's code will dump core under run-time.
When this is the case for you, then try to recompile OpenSSL
with Position Independent Code (PIC) by adding a `-fPIC' (for
GCC) or `-KPIC' (for SVR4-style compilers) to the platform
configuration line in OpenSSL's `Configure' script.
And from joerg's apache relnotes:
neko_apache relnotes wrote: When using the libssl.so keep in mind that it links agains the openssl librarys which comes with the IRIX OS. For unknown reasons linking against neko_openssl dont work and produce a core dump when try to start the webserver. It needs to tweak the src/modules/ssl/libssl.module to take care of IRIX lib32 directory and not only 'lib'.
Shall I describe it to you? Or do you want me to get you a box?
Okay, I'll give a recompile a try sometime today. Why joerg did that I don't know - normally he's pretty adamant about using IRIX libraries over Nekoware.
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
Uploaded a new build to 'beta' - hopefully that does something for you.
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
thanks.
But no luck so far.
And no clear indication of what's wrong.
*scratches head*
But no luck so far.
And no clear indication of what's wrong.
*scratches head*
Shall I describe it to you? Or do you want me to get you a box?
That one has '-KPIC' hacked in as you asked ... I suppose if it works with the system openssl and joerg used the same approach, go for it
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
Neko; if you want, you can move the
neko_fltk-1.1.7+xft.tardist
definitively to '/obsolete' now, since I've exhausted here all my tests with these release, and it will not work without some serious changes on libXft, libxrender, and lately, on fltk-1.1.7 too.
On the other hand, and if you don't bother by the AA fonts, neko_fltk-1.1.7-xft.tardist is still working perfectly with all the rest of nekoware.
Anyway, right now, and just for the sake of the completitude I'm working on a newer fltk-1.1.X release including AA fonts with the actual neko_libXft. Well see...
On the other hand, and if you don't bother by the AA fonts, neko_fltk-1.1.7-xft.tardist is still working perfectly with all the rest of nekoware.
Anyway, right now, and just for the sake of the completitude I'm working on a newer fltk-1.1.X release including AA fonts with the actual neko_libXft. Well see...
GeneratriX wrote: Neko; if you want, you can move the neko_fltk-1.1.7+xft.tardist definitively to '/obsolete' now, since I've exhausted here all my tests with these release, and it will not work without some serious changes on libXft, libxrender, and lately, on fltk-1.1.7 too.
Okay, what I did is this - renamed neko_fltk-1.1.7-xft.tardist to neko_fltk-1.1.7.tardist and moved to /current. Renamed neko_fltk-1.1.7+xft.tardist to neko_fltk-1.1.7-xft.tardist and moved to /obsolete; the script that outputs dependancy/md5sum chokes on the plus sign and I think the dash works well as an indicator that it includes xft support.
On that note - any feedback on other packages to move to /current? We've received quite a number in the past two weeks
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
nekonoko wrote: Okay, what I did is this - renamed neko_fltk-1.1.7-xft.tardist to neko_fltk-1.1.7.tardist and moved to /current.
Sure; it will replace perfectly the previous neko_fltk-1.1.rc2.tardist, adding some interesting features and fixing lots of bugs.
nekonoko wrote: Renamed neko_fltk-1.1.7+xft.tardist to neko_fltk-1.1.7-xft.tardist and moved to /obsolete;
Well, if you want because archival reasons it is fine... but you can remove these tardist if you want, since it is definitively broken, it will not work at all.
...In fact I'm already working since a few hours to have a version supporting fonts with antialiasing parting from the newer fltk-1.1.7-r5357 , which already fix a few minor bugs over the release that you moved today to /current (which was already blessed with all my tests here)... but, anyway this new r5357 is not ready to go yet, and I guess I'll have to work a little bit more before to have an stable neko_ release to share.
nekonoko wrote: the script that outputs dependancy/md5sum chokes on the plus sign and I think the dash works well as an indicator that it includes xft support.
...ahhh, then it was the plus sign, I've wondered a little about that. Good to know; I'll avoid "plusses" on middle of names next time!
nekonoko wrote: On that note - any feedback on other packages to move to /current? We've received quite a number in the past two weeks
Well, I have now all the /beta packages already installed on my box, and I've launched at least three times the ones with a GUI, and all of them started very well... no further tests beyond that...
The only ones which seems to want to make me difficult the life...
neko_gimp-2.2.12.tardist (which bombs out as soon I open an image)
neko_mozilla-1.8a5.tardist (which bombs out randomly)
BTW: ...I also have neko_dia-0.95.tardist installed, which seems to work just fine... so, is there any major bug of which I was not awared of, I mean, it was removed from nekoware?
Well, just my quickly "before-to-sleep" list!
GeneratriX wrote: neko_gimp-2.2.12.tardist (which bombs out as soon I open an image)
That one opens up images fine here ...
neko_mozilla-1.8a5.tardist (which bombs out randomly)
... and that one's not in beta
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
GeneratriX wrote:
neko_gimp-2.2.12.tardist (which bombs out as soon I open an image)
neko_mozilla-1.8a5.tardist (which bombs out randomly)
BTW: ...I also have neko_dia-0.95.tardist installed, which seems to work just fine... so, is there any major bug of which I was not awared of, I mean, it was removed from nekoware?
What were the error messages on gimp & mozilla. I bet it's the same old glib memory mangling...really need to get to the bottom of that once and for all.
I'm glad to hear dia-0.95 was working for you. It starting throw glib memory errors as well until I recompiled it against the newer version. I'll try to repackage it next week. Unfortunately, I'll be traveling a bit until then.
squeen wrote: I bet it's the same old glib memory mangling...really need to get to the bottom of that once and for all.
Does davea's post regarding rqs in the Mozilla thread have any bearing on this? He posted some possible solutions, regarding Mozilla at least:
viewtopic.php?t=10959
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
Saw it. Good info. I'll try to set up some experiments (with known failure cases).
nekonoko wrote: That one opens up images fine here ...
...mmmhhh, I'll check those GIMP's messages next time to post them here.
nekonoko wrote: ... and that one's not in beta
Touche'!
...Yeah, Mozilla is not in beta!
squeen wrote: What were the error messages on gimp & mozilla. I bet it's the same old glib memory mangling...really need to get to the bottom of that once and for all.
Well, some of them are posted here...
squeen wrote: I'm glad to hear dia-0.95 was working for you. It starting throw glib memory errors as well until I recompiled it against the newer version. I'll try to repackage it next week. Unfortunately, I'll be traveling a bit until then.
No problem; it seems to work just fine here. Anyway, I'll try to give it a deeper look with some more complex project, to see if it is still stable.
Thanks to both, guys!
Cheers,
Diego
A few updates in beta:
neko_autoconf-2.60
neko_automake-1.9.6
neko_bison-2.3
neko_bzip2-1.0.3
neko_emacs-21.4a
neko_m4-1.4.6
neko_make-3.81
neko_nano-1.3.12
neko_tar-1.15.91
neko_wget-1.10.2
neko_autoconf-2.60
neko_automake-1.9.6
neko_bison-2.3
neko_bzip2-1.0.3
neko_emacs-21.4a
neko_m4-1.4.6
neko_make-3.81
neko_nano-1.3.12
neko_tar-1.15.91
neko_wget-1.10.2
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
nekonoko wrote: A few updates in beta:
neko_autoconf-2.60
neko_automake-1.9.6
neko_bison-2.3
neko_bzip2-1.0.3
neko_emacs-21.4a
neko_m4-1.4.6
neko_make-3.81
neko_nano-1.3.12
neko_tar-1.15.91
neko_wget-1.10.2
KEWL!!!
...You're a killer build machine, Neko!
A nice solid foundation Neko! I'll pull them down and give then a test run. Thanks!
Today i have noticed a problem with 'luma' which is a python based programm to browse through ldap directorys. When trying to start the programm i get the following:
What i dont understand is the following. The luma apps was created after the last update of fontconfig so i expect that the error dont comes from the libfontconfig. But the date information confused me.
Luma was created on 11/30/2005 and the latest fontconfig package is from 10/8/2005. But when take a look to the files i get
which means 7/3/2005 for the sysmlinks. Does this means that swmgr dont 'update' symlinks from a package when installing an update?
Someone have a clue whats going wrong?
As an note: It would be fine if a packager would insert his name/email into the relnote file. Also a more complete configure line would be help when recompile something.
regards
Joerg
Code: Select all
[fuel]:~ $ luma
Traceback (most recent call last):
File "/usr/nekoware/bin/luma", line 18, in ?
from qt import *
ImportError: 1750:python: rld: Fatal Error: unresolvable symbol in /usr/nekoware/lib/libfontconfig.so.2: libiconv_open
What i dont understand is the following. The luma apps was created after the last update of fontconfig so i expect that the error dont comes from the libfontconfig. But the date information confused me.
Code: Select all
[o2k]:~ $ showfiles --/usr/nekoware/lib/libfontconfig.so.2
l 0 0 neko_fontconfig.sw.lib usr/nekoware/lib/libfontconfig.so.2
f 52281 373612 neko_fontconfig.sw.lib usr/nekoware/lib/libfontconfig.so.2.4
[o2k]:~ $ versions -n neko_fontconfig.sw.lib
I = Installed, R = Removed
Name Version Description
I neko_fontconfig 3 fontconfig-2.3.2 font configuration library
I neko_fontconfig.sw 3 Software
I neko_fontconfig.sw.lib 3 shared libraries
[o2k]:~ $ versions neko_fontconfig.sw.lib
I = Installed, R = Removed
Name Date Description
I neko_fontconfig 10/08/2005 fontconfig-2.3.2 font configuration library
I neko_fontconfig.sw 10/08/2005 Software
I neko_fontconfig.sw.lib 10/08/2005 shared libraries
Luma was created on 11/30/2005 and the latest fontconfig package is from 10/8/2005. But when take a look to the files i get
Code: Select all
o2k]:~ $ ll /usr/nekoware/lib/libfontconfig.so*
lrwxrwxrwx 1 root sys 20 7. März 2005 /usr/nekoware/lib/libfontconfig.so -> libfontconfig.so.2.4
lrwxrwxrwx 1 root sys 20 7. März 2005 /usr/nekoware/lib/libfontconfig.so.2 -> libfontconfig.so.2.4
-rwxr-xr-x 1 root sys 373612 8. Okt 2005 /usr/nekoware/lib/libfontconfig.so.2.4
which means 7/3/2005 for the sysmlinks. Does this means that swmgr dont 'update' symlinks from a package when installing an update?
Someone have a clue whats going wrong?
As an note: It would be fine if a packager would insert his name/email into the relnote file. Also a more complete configure line would be help when recompile something.
regards
Joerg
