On Thursday 21 December 2006 14:17 Egor Pasko wrote: > On the 0x246 day of Apache Harmony Gregory Shimansky wrote: > > Egor Pasko wrote: > > > On the 0x245 day of Apache Harmony Geir Magnusson, Jr. wrote: > > >> There's been some comment on the fact that I'm using GCC v4.x for the > > >> em64t builds, requiring users of the snapshot to use libstdc++ v6. > > >> > > >> Is this a real problem? Shouldn't we be using the newest major > > >> version of gcc for our builds? > > > > > > I found a relatively simple approach in [1] (but supposedly not > > > universal): > > > shell> ln -s `g++ -print-file-name=libstdc++.a` > > > shell> g++ -static-libgcc -L. -o example example.cpp > > > works on my em64t on a simple test. Modifying the build is quing to > > > be > > > somewhat painful. Volunteers wecome! > > > [1] Linking libstdc++ statically > > > http://www.trilithium.com/johan/2005/06/static-libstdc/ > > > > I am afraid we'll hit the same problem with static linking on x86_64 > > as we had with static libjpeg, libpng and liblcms. The libstdc++.a > > library in most distributions is likely built without -fPIC because it > > is required only for shared libraries. > > yes, you are right! we need libstdc++.a with -fPIC > but it is not for development, just to make binary releases and > snapshots. Yet, probably, too much...
Ok I see your point. Using it just for binary releases may be ok. Another question with static linking libstdc++ is whether it has to be linked to all VM components that use it (libharmonyvm and libem currently need it) or only one. > another alternative is 2 versions of each linux snapshot.. which I do > not like > > > While it is usually possible to create a shared library on x86 linking > > it against static libraries built without -fPIC on x86, on x86_64 it > > seems to just never work. > > > > The solution for classlib natives which need libjpeg, libpng and > > liblcms libraries could be to have our own specially compiled static > > libraries which are built with -fPIC. But now if we'll need a special > > build of gcc, it may be too much. > > > > -- > > Gregory -- Gregory
