SEO

Have I forgotten how to link a shared lib using gnutools, or has it broken sometime between osr506 and osr507mp5, or has it never worked and I just never noticed until now or... ?

What's happening is, several different apps now, they build without error, but if they produced any .so files, those .so's don't actually work. When a binary tries load the library it just crashes with killed: segmentation violation, or just "killed".

I found a little table in the programmers faq but it's either out of date or I'm just failing to figure out how to get makefiles to do the right thing at the right time. use -G to link a .so, use -G -fPIC to link things that go into a .so

I found a message from Kean from 2003 that explained some things why gcc is broken on 507 and said they were just about to release a new gnutools with an officially supported gcc 3.x for 507 that would likely be 3.4. but that of course never happened so I don't know what to do with that, other than download gcc 3.4 and see if his changes were in fact accepted. That may still not help me build it since I have gcc 2.95 from gnutools 507Kj which apparently is broken on 507. Though maybe the gcc bootstrap stages allow for things like this. I've never built gcc itself before.

I do have a native dev sys license so if there is a way that involves native cc I can do it.

I'm currently reading yet more stuff I'm googling up, such as a large patch from Kean in 2005 against gcc 4.0.3

Just figured I'd see if a short "do this:" answer is already known while I slog through all this...

--
Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

Brian K. White typed (on Sat, Apr 12, 2008 at 03:13:43PM -0400):
| Have I forgotten how to link a shared lib using gnutools, or has it broken sometime between osr506 and osr507mp5, or has it never worked and I just never noticed until now or... ?
|
| What's happening is, several different apps now, they build without error, but if they produced any .so files, those .so's don't actually work. When a binary tries load the library it just crashes with killed: segmentation violation, or just "killed".
|
| I found a little table in the programmers faq but it's either out of date or I'm just failing to figure out how to get makefiles to do the right thing at the right time. use -G to link a .so, use -G -fPIC to link things that go into a .so
|
| I found a message from Kean from 2003 that explained some things why gcc is broken on 507 and said they were just about to release a new gnutools with an officially supported gcc 3.x for 507 that would likely be 3.4. but that of course never happened so I don't know what to do with that, other than download gcc 3.4 and see if his changes were in fact accepted. That may still not help me build it since I have gcc 2.95 from gnutools 507Kj which apparently is broken on 507. Though maybe the gcc bootstrap stages allow for things like this. I've never built gcc itself before.
|
| I do have a native dev sys license so if there is a way that involves native cc I can do it.
|
| I'm currently reading yet more stuff I'm googling up, such as a large patch from Kean in 2005 against gcc 4.0.3
|
| Just figured I'd see if a short "do this:" answer is already known while I slog through all this...

I'm looking at my 5.0.7 box. Mutt, pcl6, and mogrify (from ImageMagick)
are three examples that I just checked. I compiled them with gcc 2.95.3,
and each of them in turn loads one or another /usr/local/lib/libXYZ.so, also
compiled by me with the same gcc.

What further details would you like?

--
JP

----- Original Message -----
From: "Jean-Pierre Radley" <jpr@jpr.com>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Saturday, April 12, 2008 3:35 PM
Subject: Re: linking shared libs with gnutools


> Brian K. White typed (on Sat, Apr 12, 2008 at 03:13:43PM -0400):
> | Have I forgotten how to link a shared lib using gnutools, or has it broken sometime between osr506 and osr507mp5, or has it never worked and I just never noticed until now or... ?
> |
> | What's happening is, several different apps now, they build without error, but if they produced any .so files, those .so's don't actually work. When a binary tries load the library it just crashes with killed: segmentation violation, or just "killed".
> |
> | I found a little table in the programmers faq but it's either out of date or I'm just failing to figure out how to get makefiles to do the right thing at the right time. use -G to link a .so, use -G -fPIC to link things that go into a .so
> |
> | I found a message from Kean from 2003 that explained some things why gcc is broken on 507 and said they were just about to release a new gnutools with an officially supported gcc 3.x for 507 that would likely be 3.4. but that of course never happened so I don't know what to do with that, other than download gcc 3.4 and see if his changes were in fact accepted. That may still not help me build it since I have gcc 2.95 from gnutools 507Kj which apparently is broken on 507. Though maybe the gcc bootstrap stages allow for things like this. I've never built gcc itself before.
> |
> | I do have a native dev sys license so if there is a way that involves native cc I can do it.
> |
> | I'm currently reading yet more stuff I'm googling up, such as a large patch from Kean in 2005 against gcc 4.0.3
> |
> | Just figured I'd see if a short "do this:" answer is already known while I slog through all this...
>
> I'm looking at my 5.0.7 box. Mutt, pcl6, and mogrify (from ImageMagick)
> are three examples that I just checked. I compiled them with gcc 2.95.3,
> and each of them in turn loads one or another /usr/local/lib/libXYZ.so, also
> compiled by me with the same gcc.
>
> What further details would you like?

Well, I know this is asking a lot but, I guess config.status or config.log from ImageMagick ?
That should show me your PATH and various decisions made all at once.
There may be system info you don't want to disclose in those. They log your whole set/env environment for starters.
Asking even more, Full output of a build captured with tee would be even better since it would show actual gcc command lines.

It's an unnecessarily large package for this but of the ones you mentioned, it happens to be one in particular that I've built several times before on other, older boxes, which does include and use a .so it built for itself, and yet the current version fails for me today on osr507mp5/gnutools507Kj. my pcl6 is a recent and working build on this box, but the only .so's it loads are libc and libm.

On the same (new) box, the ImageMagick from my web page includes a .so, and successfully uses it.
# ldd /usr/local/bin/convert
/usr/local/bin/convert needs:
libMagick.so.6 => /usr/local/lib/libMagick.so.6
....

But, that package, including the .so were built on 506.
I'm going to try just rebuilding the exact same version, the very same tar that was created just after building on that lost 506 box, with the same command line since I logged that in a readme in the tar, And then compare the result against the same tar before rebuilding.

thanks

--
Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

Brian K. White typed (on Sat, Apr 12, 2008 at 04:06:42PM -0400):
| > What further details would you like?
|
| Well, I know this is asking a lot but, I guess config.status or config.log from ImageMagick ?
| That should show me your PATH and various decisions made all at once.
| There may be system info you don't want to disclose in those. They log your whole set/env environment for starters.
| Asking even more, Full output of a build captured with tee would be even better since it would show actual gcc command lines.

I'll send them to you directly.

BTW, I just found out that there's a spin-off called GraphicsMagick,
which I think I'll be adopting from now on in preference to IM.


--
JP