2011/8/15 Peter FELECAN <[email protected]>: > Maciej Bliziński <[email protected]> writes: > >> 2011/8/15 Peter FELECAN <[email protected]>: >>> Maciej Bliziński <[email protected]> writes: >>> >>>> 2011/8/14 Maciej Bliziński <[email protected]>: >>>>> ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory >>>>> ld: fatal: File processing errors. No output written to >>>>> .libs/liblto_plugin.so.0.0.0 >>>>> >>>>> Does anyone have an idea where to look for diagnostic information? >>>> >>>> If anyone wants reproduce the problem, all code is committed and >>>> available in pkg/gcc4/branches/bootstrap-4.6. >>> >>> Are you trying to build with Sun's C compiler? (I never succeeded to build >>> gcc with that compiler) In the affirmative you'll have a heavy time >>> generating the Ada compiler. >> >> Yes, I am trying to get the stage 1 gcc built with Sun Studio. I've >> found a proof of concept how to work around the libtool problem above, >> but it's not the proper fix yet. >> >> Dago got the 4.3.6 version to build. Built packages generate a ton of >> checkpkg errors, such as sparcv8+ binaries and file conflicts. It >> will take a while to clean all that up. > > And how did you generate the Ada compiler?
For 4.3.6, it built fine. The 4.6.1 version requires the PPL library, which I got to compile for sparc, but not for i386, so I did not attempt to build Ada for 4.6.1. When you were working on it, did you also got stuck on PPL? Meanwhile, I talked with Dago on IRC; Dago took a look at PPL and stamped out compilation errors in PPL. >> In general, I find the existing gcc recipe very complex and I'll see >> if I can simplify it. > > Complex package, complex recipe. > >> I have a question: What is the rationale behind having the gcc package >> split off to so many subpackages? I understand splitting off packages >> with the shared libraries, this is required to make the catalog >> maintainable. But all the specific compilers? It can't be the disk >> space argument, because if you have a development machine, you need to >> have a lot of disk space anyway. What is it then? If there is no >> really good reason, I would be inclined to switching gcc to a single >> package + shared libraries -- this way its maintenance will be much >> easier. > > non exhaustive reasons for which the packaging is done that way: > > 1. no need to install all the compilers when one needs only 1 language > > 2. traditional packaging on all the platforms that I know is done this > way > > 3. there are common components which are not libraries > > The disk space is not an argument in our case but it is in other cases. > > Unfortunately you'll end up with more packages than the current ones and > in my opinion that it's not a bad thing. Good granularity is a quality > factor for our project. Fair enough, I'll slice the package separating out language-dependent files into subpackages. The main difference in packaging between the previous and the new gcc packages will be that I'm putting the shared libraries into /opt/csw/lib and creating library-specific packages, conforming to our packaging policy. There is one issue, in which gcc3corert and gcc3g++rt try to deliver the same files, so we need to repackage them in a way that makes room for gcc4 shared libs. Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
