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?
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
