harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [classlib] Building on x86_64
Date Fri, 10 Nov 2006 01:18:33 GMT
Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
>> Hello
>>
>> Today I tried to check what happens on x86_64 and I think I've found 
>> some issues which need discussion
>>
>> 1. When classlib starts its built it tries to link 3 libraries and 
>> headers to depends/libs/build/{jpeg,lcms,png} directories. On x86_64 
>> SuSE9 it has failed for me to find lcms and png libraries because they 
>> happen to be in /usr/lib64. This should not be the case on Gentoo 
>> because /usr/lib is a link to /usr/lib64, but it looks like not all 
>> distributions follow this way. So probably searching /usr/lib64 first 
>> should be done on x86_64.
>>
>> 2. I've linked liblcms.a and libpng.a in /usr/lib64 by hands but then 
>> linker complained that they cannot be used because relocations have to 
>> be done. I've replaced links with links to *shared* libs and it seems 
>> to have worked ok. For some reason libjpeg.a found in /usr/lib didn't 
>> cause the problems. But anyway, I'd like to ask a question, why do we 
>> want static linking? Not all distributions supply static versions of 
>> these libraries, for example I found none in Fedora 5 even on x86. Why 
>> not switch to shared libraries?
> 
> I do think we want to use static compilation to be sure of what we're 
> running with.

But what if static library was not compiled with -fpic and just cannot 
be linked to dynamic library of classlib? I didn't imagine the problem, 
it does happen, linker complains that I need to recompile it with -fpic.

When we link against static libraries supplied by the distribution we 
don't control the library as well, it was built somewhere by someone 
with unknown compilation options and the version of package is not 
really known. What is the difference with dynamic libraries here? What 
to do with distributions which no longer supply static libraries for 
needed packages?

We could of course end up checking binaries in into SVN just like we did 
ICU libraries. Now that I think of it, it may be the only option because 
HDK binary snapshot has to work on any linux installation, even one 
which don't have lib{png,jpeg,lcms}.so installed at all.

>> 3. ICU libraries in HARMONY-1678 had to be linked as well because 
>> build wants libicu*.so.34 while libraries in the archives have 
>> libicu*.so.34.1 names. Shouldn't they be added to SVN like 
>> depends/libs/linux.x86 ones with the same names as build wants?
>>
>> 4. Classlib always builds to "deploy" directory. When working with 
>> different architectures it is good when output directories for all 
>> files including object files are different. Otherwise it is necessary 
>> to create separate repositories for every one of them or do clean 
>> rebuild on every switch and never forget which version of classlib is 
>> currently built. Could we change classlib build to create object files 
>> in directories with architecture postfix and final output to something 
>> like "deploy-x86_64"? Also we could separate debug/release built files 
>> in the same way.
> 
> +1

-- 
Gregory


Mime
View raw message