Summary: | Add libg2c-3 ebuild to the tree | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | webb.sprague |
Component: | Current packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | erict, icb1, sci |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
webb.sprague
2006-06-16 07:45:36 UTC
Yes. The Fortran compiler (and therefore the runtime library) changed to gfortran. You need to recompile your Fortran apps when you switch to gcc 4. I'm going to change this to a request for an ebuild providing libg2c, similar to what libstdc++-v3 does to provide a libstdc++.so.5 when gcc 3.4 switched to the .so.6. (In reply to comment #1) > You need to recompile your Fortran apps when you switch to gcc 4. Just FYI, I did recompile numpy after switching to gcc-4.1.1 via eselect; it didn't help. Perhaps adding the stuff analogous to stdc++ will take care of that -- I don't really understand what you said, but that is fine. (In reply to comment #2) > (In reply to comment #1) > > You need to recompile your Fortran apps when you switch to gcc 4. > > Just FYI, I did recompile numpy after switching to gcc-4.1.1 via eselect; it > didn't help. Install portage-utils, and try this command: qlist numpy | xargs ldd | grep -e g2c -e gfortran Actually I bet it's that eselect-compiler bug again. Look at the files in /etc/eselect/compiler/ and delete any line like alias_gfortran=g77 or alias_g77=gfortran. Then switch to gcc-4 again, and delete /usr/bin/*g77. (In reply to comment #4) > Actually I bet it's that eselect-compiler bug again. > > Look at the files in /etc/eselect/compiler/ and delete any line like > alias_gfortran=g77 or alias_g77=gfortran. Then switch to gcc-4 again, and > delete /usr/bin/*g77. Here is the what I did, but it didn't change the error: (1) edit /etc/eselect/compiler/* to remove said lines (2) mv'ed f77 to _f77, etc (3) eselected to gcc-3.3.6 (4) eselected back to gcc-4.1.1 (5) unmerged numpy (6) remerged numpy (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > You need to recompile your Fortran apps when you switch to gcc 4. > > > > Just FYI, I did recompile numpy after switching to gcc-4.1.1 via eselect; it > > didn't help. > > Install portage-utils, and try this command: > > qlist numpy | xargs ldd | grep -e g2c -e gfortran After a fresh un/merge of numpy: cowboy ~ # qlist numpy | xargs ldd 2>/dev/null | grep -e g2c -e gfortran libg2c.so.0 => not found libg2c.so.0 => not found libgfortran.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgfortran.so.1 (0xb7070000) libg2c.so.0 => not found libg2c.so.0 => not found Has there been any progress on this? I need libg2c.so.0 for a binary program and gcc4-4.1.1-r3 still doesn't provide it. (In reply to comment #7) > Has there been any progress on this? I need libg2c.so.0 for a binary program > and gcc4-4.1.1-r3 still doesn't provide it. Nope, no progress. It will eventually be a standalone libg2c-v3 ebuild if anyone gets around to putting it together. Until then, you can work around the issue by switching your compiler to gcc3 while running the program. I actually just downloaded a debian package called libg2c0_3.4.6-5_i386.deb, extracted it with dpkg and placed the library in /usr/lib. Everything works great. I'd rather do this than have to reinstall gcc3.4. Shouldn't this be a relatively easy ebuild to make? (In reply to comment #9) > Shouldn't this be a relatively easy ebuild to make? Sure, if you're familiar with gcc's weird build process and our eclasses to control it. Any progress here, Donnie? Nope. Anyone care? I'd figured most people these days make gcc-4 binaries available. Hit today a package which needs them. But thanks to debian, their package helps as a first workaround. Will see what the next version brings, but I am still waiting for the license. So finaly the new license arrived. But same linking problem: gfortran -Wl,-O1,--hash-style=gnu,--sort-common -o cyanaexe.gnu cyana.o accel.o acostt.o angles.o array.o assign.o atoms.o build.o caliba.o cgmin.o chkgrd.o dihgrd.o dihrng.o discon.o drange.o fcn.o gencor.o comdco.o compik.o copy.o discom.o gener.o geom.o getaco.o getang.o getcco.o getcor.o getdco.o getlib.o getori.o getpik.o getpro.o getseq.o getxpl.o glomsa.o grad.o grid.o griaco.o gricor.o grifra.o grimem.o grisea.o grisrt.o griswa.o grdint.o hbonds.o htable.o iatom.o inerta.o iniseq.o jcoupl.o lineq.o makehb.o libcnv.o links.o lisrms.o makpik.o mean.o minim.o moddco.o modmul.o moldyn.o multi.o peaks.o pikcal.o pseudo.o putaco.o putang.o putass.o putcco.o putcor.o putdco.o putpik.o putpro.o ranges.o ranstr.o readf.o rmsd.o rotat.o select.o setdco.o setlev.o setlvw.o setsvw.o stable.o struct.o strcal.o sysfun.o sysvar.o setswa.o tfadd.o tree.o vdwatm.o veloc.o violat.o viosta.o vtable.o writef.o ../inclan/inclan.a ../inclan/inclan.a(unix.o): In function `istamp_': unix.f:(.text+0x2f): undefined reference to `stat_' ../inclan/inclan.a(unix.o): In function `uxdate_': unix.f:(.text+0x5a): undefined reference to `time_' ../inclan/inclan.a(unix.o): In function `uxtime_': unix.f:(.text+0x1ce): undefined reference to `time_' ../inclan/inclan.a(unix.o): In function `iwall_': unix.f:(.text+0x2f4): undefined reference to `time_' ../inclan/inclan.a(unix.o): In function `timnow_': unix.f:(.text+0x466): undefined reference to `etime_' ../inclan/inclan.a(unix.o): In function `igtpid_': unix.f:(.text+0x496): undefined reference to `getpid_' ../inclan/inclan.a(unix.o): In function `isystm_': unix.f:(.text+0x49b): undefined reference to `system_' collect2: ld returned 1 exit status make[2]: *** [cyanaexe.gnu] Error 1 If there is any chance to get this I would be happy. i have the same issue needing libgc2 for a binary program. any progress on the ebuild for it? (In reply to comment #15) > i have the same issue needing libgc2 for a binary program. any progress on the > ebuild for it? > I also need libg2c.so for some older software that will no longer compile. Hopefully we do not need this anymore these days. But if we do, we need the help of the toolchain guys to pack it. aparently i figured out a work around for this before as i see my comment above. i'm using the same binary program again that needs this, and libg2c is missing again (emerge --clean maybe wiped it out?). i have the same issue needing libgc2 for a binary program. any progress on the ebuild for it? i have no idea how i fixed this before... found an ebuild here: https://websvn.j-schmitz.net/filedetails.php?repname=Portage+Overlay&path=%2Febuilds%2Fdev-libs%2Flibg2c%2Flibg2c-3.4.6.ebuild&rev=933 i had to change the source_uri to fetch the amd64 dpkg and i had to use keyword **, but this seemed to work... |