SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have installed an app ( compilation is very difficult... the build system is quite awkward... several makefiles, no centralized configure script... ) called Salome-5.1.1 www.salome-platform.org;
It is a Pre/Post-processing application used in engineering of structures.
This is a Free-gpl app that calls for various dependencies, like Python 2.5.x ( which I have downgraged ), libgfortran.so.1, which I enabled with a hackerish trick, like
in /opt/salome, type, ln -s /usr/lib64/libgfortran.so.3 libgfortran.so.1
and creating a launching script in /usr/local/bin like this... :
After changing exec permissions to this script, to run it as user, the app really starts... but one of its functions, the ability to mesh a solid into finite elements, fails because there is no libg2c.so.0
So I ask you forum, where ( which package or SlackBuild ) will give me libg2c.so.0...?
Do I hav to create a chroot to be able to run this app...?
If so... this is probably too much... :-( I currently run this in CaeLinux/*buntus till 8.10 ( never tried more recent versions ) and Debian Lenny... but most of these distros are "old"...
Is there any possibility of me enabling libg2c.so.0 in Slackware64 13...?
I think that simply throwing a libg2c-so.0 from a Lenny into /opt/Salome in Slackware64 13, and resorting to the LD_LIBRARY_PATH "hackability" wont do... some symbols in libg2c.so.0 from Lenny will be unreferenced in the glibc from Slackware, etc. etc..
Thx for your support, one question though... In case i convert the rpm to tgz... ( how do I do it... is there any "alien" slackbuild, or must I extract the object(s) in the rpm and repackage it as *.tar.gz and mv *.tar.gz *.tgz ? ) won't there be confilcts with the rest of the system when accessing this lib, or is this kind of "independent"... ( and can be placed anywhwere provided LD_LIBRARY_PATH "sees" it...?
One other solution... ( pls correct me If I am wrong here... I am still a "tiny geek", not a "REAL GEEK" ... :-D )
Could i grab the Slackbuild of some gcc-3.4.x from previous Slackware versions, rebuild it as 64bits slackware package, and drop it to /usr/local/* ( after remastering the gcc-4.4.x.SlackBuild script )...?
I.E. Should the "whole pack" of gcc-3.x be built and installed to prefix /usr/local, would Slackware applications be able to "see" its libs and compilers without trashing away my whole system...? ( one can always removepkg the thing in case something goes wrong... )
in return you will get nameofpackage.tgz. Which you better look at first. Something like tar tvf nameofpackage.tgz. If you do not see any danger in it, than installpkg nameofpackage.tgz. I did this for binary Epson TX659 drivers. And it worked.
Thx for your support, one question though... In case i convert the rpm to tgz... ( how do I do it... is there any "alien" slackbuild, or must I extract the object(s) in the rpm and repackage it as *.tar.gz and mv *.tar.gz *.tgz ? ) won't there be confilcts with the rest of the system when accessing this lib, or is this kind of "independent"... ( and can be placed anywhwere provided LD_LIBRARY_PATH "sees" it...?
rpm2tgz is a tool to do that, but be wary of the results, I've never used it and don't trust it. If I understand you correctly, conflicts shouldn't be an issue as long as it was compiled for your architecture.
Quote:
Could i grab the Slackbuild of some gcc-3.4.x from previous Slackware versions, rebuild it as 64bits slackware package, and drop it to /usr/local/* ( after remastering the gcc-4.4.x.SlackBuild script )...?
I.E. Should the "whole pack" of gcc-3.x be built and installed to prefix /usr/local, would Slackware applications be able to "see" its libs and compilers without trashing away my whole system...? ( one can always removepkg the thing in case something goes wrong... )
Yes you could if you wanted. In that case after installing it to /usr/local/, you should adjust your PATH when building certain software so /usr/local/bin/gcc gets called rather than /usr/bin/gcc
edit: Just realized that by default /usr/local/bin occurs first in PATH. So it's the other way around. When building software with the newer version of gcc, you'll want to make sure /usr/bin occurs first
Distribution: PCLinuxOS2023 Fedora38 + 50+ other Linux OS, for test only.
Posts: 17,511
Rep:
Quote:
Could I grab the Slackbuild of some gcc-3.4.x from previous
Slackware versions, rebuild it as 64bits slackware package,
and drop it to /usr/local/* ( after remastering the
gcc-4.4.x.SlackBuild script )...?
Use src2pkg to convert rpm packages instead of rpm2tgz -if you must use rpm's at all. src2pkg will check and correct eprms which rpm2tgz will not do. Just call src2pkg like you normally do -substituting the name of the rpm for the regular tarball name:
src2pkg name-of.rpm
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.