libg2c.so.0 in Slackware
 

Hi Forum

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... :

echo 'export LD_LIBRARY_PATH=/path/to/salome:$LD_LIBRARY_PATH$$. /source/environment/file.sh&&/call/launching/script/file.sh' > /usr/local/bin/salome

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..

Any suggestions here...?


Thanks in advance

BRGDS

Alex

Well here's the first hit that came up after a Google search

http://lists.debian.org/debian-amd64.../msg00650.html

[crazy idea]You can try getting a rpm from rpm.pbone.net and convert it to tgz.[/crazy idea]

@ ~sHyLoCk~ : That is in fact the available solution :

http://mirror.centos.org/centos/5.4/os/x86_64/CentOS/
http://mirror.centos.org/centos/5.4/...6-4.x86_64.rpm
> > compat-libf2c-34-3.4.6-4.x86_64.rpm

.. providing /usr/lib64/libg2c.so.0 -> libg2c.so.0.0.0
.. which is the solution I use in Slackware ( but as 32 bit.)

The compat-gcc-34-g77-3.4.6-4.x86_64.rpm
http://mirror.centos.org/centos/5.4/...6-4.x86_64.rpm
can be recommended too, to have a genuine g77.
.....

I know you are using Slackware, and this is from Ubuntu, but it might help:

Hi ppl

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... )


BRGDS

Alex

No, you simply run (as root?):
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.

brgrds,
Vladimir

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.

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

Hi Voycis

Just for curiosity... where ( which file sets the environment variable ) is PATH set up first, besides of .bashrc (.cshrc ) or shell comand...?

BRGDS

Alex

The first config file that bash reads is /etc/profile

May be have a look at
http://connie.slackware.com/~alien/slackbuilds/
> > gcc-3.4.6 = the last one providing g77 ..
http://connie.slackware.com/~alien/slackbuilds/gcc34/
.. which is installed to /usr/gcc34/
.. and add fortran to the Slackbild configure line :
--enable-languages=c,c++
http://connie.slackware.com/~alien/s...c34.SlackBuild

Installing to /usr/local/ will cause conflicts.
(( /usr/local/gcc34/ could be usable )).
.....

How come?

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

@ voyciz # 12

Conflicting files : libgcc_s.so.1 , libgcc_s.so

There may be more, and it is for very good reasons,
that the 'Alien Slackbuild' gcc 3.4.6 has a hide away
location in /usr/gcc34/
http://connie.slackware.com/~alien/slackbuilds/gcc34/
.....

# 6
No, there are no conflicts. "Compat" packages are meant
to be installed, when the system compiler is also present.

Just like in Debian, where you often can have four
different compilers installed at the same time.
.....