harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] which version of gcc to use for distributables?
Date Mon, 25 Dec 2006 07:37:29 GMT
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


Mime
View raw message