On the 0x248 day of Apache Harmony Geir Magnusson, Jr. wrote: > On Dec 22, 2006, at 8:29 AM, Gregory Shimansky wrote: > > > 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. > > I don't think so - don't we want to be developing and testing with > the same artifacts that we would ship to users?
We want, in ideal situations. We may test statically linked libstdc++ on CC (and, sure, have a consice HOWTO for building user-oriented binaries) IMHO, avoiding libstdc++ version dependency makes much more good to users than "same linking mode as developers have". Let's assume that GNU linker is well-tested (and problems with our build system will be caught quickly in libstdc++-static mode) Other JVMs do not have deps on libstdc++, we can be no worse .. relatively easily. Performance won't degrade on x86, that's for sure, x86_64 is a question .. but C++ impact is not significant anyway > > 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 > > -- Egor Pasko
