WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Firefox 3.5  (Read 2269 times)

Offline lz

  • Newbie
  • *
  • Posts: 5
Firefox 3.5
« on: July 04, 2009, 07:08:12 AM »
Runing Tiny Core Linux as client on vmware server 2.0 with 512 MByte allocated for the client I can install both TCE and TCZ without any problem (at least far as I can see in the terminal) but it does not start. Starting in terminal gives:

/usr/local/firefox-official/firefox-bin: error while loading shared libraries
ibasound.so.2: cannot open shared shared object file: no such file or directory

As new to Tiny Core Linux I am not sure if this is my fault or if there is a bug in the package. Anybody?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14630
Re: Firefox 3.5
« Reply #1 on: July 04, 2009, 08:02:46 AM »
Looks like you need the libasound extension

Offline lz

  • Newbie
  • *
  • Posts: 5
Re: Firefox 3.5
« Reply #2 on: July 04, 2009, 10:31:32 AM »
Thanks for the answer. It works if I install libasound.tce first, before firefox. As I understand it Tiny Core Linux package system solves dependencies automaticaly and installs all necessary libraries. This does not happen with Firefox. So my question is not fully answered. Is it a bug or is it my fault?

By the way, thanks for this crispy distribution!

Offline Jason W

  • Administrator
  • Hero Member
  • *****
  • Posts: 9730
Re: Firefox 3.5
« Reply #3 on: July 04, 2009, 10:54:58 AM »
Though Firefox requires the alsa libs to operate, I do not like putting either ALSA or OSS in .dep files as that will cause a conflict if someone is already running one of them.  Installing alsa when running OSS or vide versa will mess up the operation of the running sound system since their modules are automatically loaded.

But since the libasound libs are required, I may well make that a dependency as that extension is made from the alsa one and will not cause a conflict with either alsa or oss.

Offline lz

  • Newbie
  • *
  • Posts: 5
Re: Firefox 3.5
« Reply #4 on: July 04, 2009, 11:15:18 AM »
I suppose that in a system with limited resources there could be a mechanism which leaves the final solution of the conflict resolution to the user. Something should happen at installation time (an intelligible message that a dependency is missing, suggestion for some possible resolution and creation of the start script for the applications, with similar information) and another thing should happen at run time when the start script for that application is run. In any case an installation would not go on if a dependency cannot be met. It probably makes the packaging more complicated but on the other hand only the user of a (limited) system knows his priorities.