Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
151 user(s) are online (132 user(s) are browsing Forums)

Members: 0
Guests: 151

more...

Support us!

Headlines

 
  Register To Post  

OS4.1.2 bug: libbz2.so missing symlink
Just can't stay away
Just can't stay away


See User information
The -soname when building should have been libbz2.so.1.0.4, but due to a typo, is libbz2.so.1.0, meaning although there is a soft-link to libbz2.so, the OS cannot find the library if a program is built with it.

Edit: Changed my mind. All that is missing is a symlink. http://www.amigans.net/modules/newbb/ ... t_id=57493#forumpost57493


Edited by MickJT on 2010/10/5 18:11:42
Edited by MickJT on 2010/10/6 5:10:57
Edited by MickJT on 2010/10/6 5:11:41
Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@MickJT

makelink sobjs:libbz2.so.1.0 sobjs:libbz2.so.1.0.4 soft

libcairo.so is a bit dodgy as well, because it references libpng.so which is linked to libpng12.so (with the same soname), resulting in the linker creating warnings. If you try to upgrade to libpng 1.4 you can't because libcairo uses something libpng14.so doesn't have, repointing the libpng.so thus creates problems, and linking against two different libpngs is not advised.

Inter-version compatibility isn't high on the list of shared object programmers' priorities, unfortuantely.

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Quite a regular
Quite a regular


See User information
@Chris

thx for the tip !

I have upgraded some archivers and got the following error each time I reboot : "failed to load shared object libbz2.so.1.0" which is very annoying...

with the command you wrote, everything is fine again

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Just can't stay away
Just can't stay away


See User information
@Lio

The soname is actually probably correct (unlike I initially thought in my first post which was a while back), but a symlink is missing.

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@Lio

Quote:
I have upgraded some archivers


One of them being XAD 7-Zip, presumably

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Quite a regular
Quite a regular


See User information
@Chris

Quote:

Chris wrote:
@Lio

Quote:
I have upgraded some archivers


One of them being XAD 7-Zip, presumably


yes exactly !

(alongside rar and xfd but I did not know which one was generating this error, because even after renaming them, the error was still there)

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@Chris
Quote:
Inter-version compatibility isn't high on the list of shared object programmers' priorities, unfortuantely.

Or maybe some programmers don't know what the soname is and how to use it properly on the Amiga?

It might help if you could write up a short tutorial on how to set, change and maintain the soname in Amiga shared objects. I don't believe this information is anywhere in the SDK yet. I would love to include any detailed information you might have.

There are tutorials on shared objects used on other operating systems but we need specific information for Amiga OS which can be included in the SDK.

ExecSG Team Lead
Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@ssolie

Quote:
Or maybe some programmers don't know what the soname is and how to use it properly on the Amiga?

It might help if you could write up a short tutorial on how to set, change and maintain the soname in Amiga shared objects. I don't believe this information is anywhere in the SDK yet. I would love to include any detailed information you might have.


I have no detailed information. In fact, I have no information on this subject at all other than what I've deduced myself, which is:

The soname should contain the major version number only (major version numbers are bumped if the API changes).
Optionally, the shared object itself can be named with the full version number, with a filesystem link from soname to the file. (personally I don't see the point, just name the shared object same as the soname and be done with it)
Developers only, create a filesystem link from sdk:local/newlib/lib/shared object name without any version numbering to sobjs:soname

The easiest way to get the soname correct if the shared object doesn't build with the right one by default, and uses libtool, is to set:
version_type=freebsd-elf
You'll need to modify libtool anyway to set the two deplibs lines to "pass_all" and "yes" respectively, so might as well change version_type at the same time.

That's the only words of wisdom I have, and I'm not guaranteeing they are correct.

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Just can't stay away
Just can't stay away


See User information
@Chris

deplibs_check_method needs to be set to pass_all, nothing else (in my experience).

If the soname isn't correct and libtool is used, I just change the ".so" suffix to be .so.version.number

Works well.

For reference, creating a shared library is done with:

gcc -shared -Wl,-soname,libSomething.so.1.4 -o libSomething.so.1.4 object.o files.o here.o

as an example.

If you're doing it manually and don't know what object files to include. Just peek inside the static library and have a look. Don't extract the .a, it won't have the right information in the object files to make it back into a library (either to static again, or shared).


Edited by MickJT on 2010/10/12 12:51:20
Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Just can't stay away
Just can't stay away


See User information
This starts sounding like we will be in dependency hell with these shared objects some day ?! Also SFS and JXFS doesn't handle links like FFS does. Also Workbench doesn't show if something is a link on those filesystems. So backuping and trying to restore your backup of SObjs usually breaks something between those infinite numbers of links pointing to each other (and cross). Same goes to SDK. (When using Workbench to copy files.)

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@TSK

Quote:
Also SFS and JXFS doesn't handle links like FFS does. Also Workbench doesn't show if something is a link on those filesystems.


I don't know about SFS, but JXFS handles links fine. Make sure you use softlinks rather than hardlinks, as hardlinks are a bit dodgy from a user's perspective and tend to change back to normal files (on JXFS but not FFS) for reasons Joerg will recite but I don't understand.

@MickJT

Quote:
deplibs_check_method needs to be set to pass_all, nothing else (in my experience).


I think I had to set "yes" to get the dependencies to compile into the SObj. Otherwise you get something relying on libz.so but it doesn't list it on a readelf -d, and the app using that shared object then tends to crash.

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@Chris
I just uploaded a new version of ListDynDep to OS4Depot. It will now print the SONAME along with the dependencies. This should make it a bit easier to figure out which files will be picked up by your executables.

Please let me know if you find it useful.

ExecSG Team Lead
Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Not too shy to talk
Not too shy to talk


See User information
@ssolie

Quote:

ssolie wrote:
@Chris
Quote:
Inter-version compatibility isn't high on the list of shared object programmers' priorities, unfortuantely.

Or maybe some programmers don't know what the soname is and how to use it properly on the Amiga?


I think so. There are still many questions about details about how shared objects are managed.

Quote:
It might help if you could write up a short tutorial on how to set, change and maintain the soname in Amiga shared objects. I don't believe this information is anywhere in the SDK yet. I would love to include any detailed information you might have.

There are tutorials on shared objects used on other operating systems but we need specific information for Amiga OS which can be included in the SDK.


I did put information here on utilitybase.com but that's not enough.

From the SDK and the dev team, I would like to see some rules about naming and the policy about the replacement of some core shared objects (png, jpeg, ...) about which we faced compatibility problems.

Go to top
Re: OS4.1.2 bug: libbz2.so was built improperly
Amigans Defender
Amigans Defender


See User information
@ssolie

Yes, it is useful. I had the old version installed but had forgotten about it.

What would be really useful is if the ALL switch could be combined with something like UNIQUE, to create a complete list of all shared objects required by a program (but only listing each SObj once).

That way you can quickly get a list of everything you need if transferring an app to another system, or creating a complete archive.

Go to top
OS4.1.2 bug: libbz2.so missing symlink
Just can't stay away
Just can't stay away


See User information
@Chris

Quote:

I think I had to set "yes" to get the dependencies to compile into the SObj. Otherwise you get something relying on libz.so but it doesn't list it on a readelf -d, and the app using that shared object then tends to crash.


You mentioned "pass_all" in this post. http://www.amigans.net/modules/newbb/ ... t_id=57507#forumpost57507

Only deplibs_check_method is checked for "pass_all". The other, link_all_deplibs is by default set to "unknown". As long as link_all_deplibs isn't "no", then it's considered yes.

I haven't had any issues doing it this way. My shared libvorbis.so looks for libogg.so. Even if it didn't, any program being linked against libvorbis.so should be linked against libogg.so anyway.

I haven't come across any programs that are linked with one .so, like libvorbis.so, and libogg.so is not linked in the main executable, but only in libvorbis.so. If you tried doing that, the program can't be linked.

I did a little "Hello World" test here.

5.RAM Disk:> gcc -use-dynld -lvorbis -o hello hello.c
ld: warning: libogg.so, needed by /SDK/local/newlib/lib/libvorbis.so, not found (try using -rpath or -rpath-link)
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_writetrunc'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_writeinit'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_look'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_bytes'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_writeclear'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_adv'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_get_buffer'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_readinit'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_read'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_reset'
/SDK/local/newlib/lib/libvorbis.so: undefined reference to `oggpack_write'

If libogg.so was not a dependency of libvorbis.so, those "undefined references" would still exist.

Edit: New libtiff 3.9.4 shared object uploaded to OS4Depot. Didn't do anything special. Modified libtool with "pass_all". The .so has the dependencies in there, libz (libz.so.1) and libjpeg (libjpeg.so.8).

Edit2: According to other distros, it should be libtiff.so.3. Hmm. I can't see where in the source it would name it that. I'll look into it later.


Edited by MickJT on 2010/10/12 14:45:16
Edited by MickJT on 2010/10/12 14:53:12
Edited by MickJT on 2010/10/12 15:13:38
Edited by MickJT on 2010/10/12 15:14:17
Go to top
Re: OS4.1.2 bug: libbz2.so missing symlink
Amigans Defender
Amigans Defender


See User information
@MickJT

Quote:
Edit2: According to other distros, it should be libtiff.so.3. Hmm. I can't see where in the source it would name it that. I'll look into it later.


Set version_type=freebsd-elf

Your other points are noted

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project