[okl4-developer] Using Gcc 4.1/4.3

Jean-Christophe DUBOIS jcd at tribudubois.net
Tue May 13 21:10:09 EST 2008


As a test, I tried to compile OKL4 2.1 with GCC 4.2 and I got a swarm of
various warnings as it seems GCC 4.2 is a lot more strict on various aspect
of C and C++. As the OKL4 Makefiles are set to consider warnings as errors
(at lest in C++) the compilation would abort quite fast. 

After overriding this setting (just to check) the compilation was able to
proceed until I got to the python program that reformat the various
generated ELF files. My build system being an x86_64 system the python
script seems to have trouble with converting native 64 bits to 32 bits
numbers in the various struct.pack() function calls. I left there (I may
come back later) but the source code seems to be able to compile on 4.2
although quite a bit of fixing should be required to get it to compile
without warnings with newer toolchains and I have not been able to test the
resulting output yet.

For now, I am back to a 32 bits build host with the recommended toolchain.

JC 

On Tue, 13 May 2008 18:12:22 +1000, Geoffrey Lee <glee at ok-labs.com> wrote:
> On Thu, May 08, 2008 at 08:50:22PM +0530, G S Madhusudan wrote:
>> 1. Apps will be native and Linux based. But down the road, I am hoping
> we
>> get rid of Linux (the goal of the project is in fact to find an
>> alternative to Linux !)
>>
>> 2. I am trying to build a standard L4 env for network appliances and the
>> idea is to get 3rd party
>> modules to be dynamically installable. As you can see, having a std tool
>> chain makes this
>> a little easier, otherwise we are bound to see issues with lib
>> incompatibility. I personally
>> do not have a problem with a custom toolchain, having used cross
>> complier tools
>> for the past 25 years ! But I want the env to be used for teaching and
>> maybe some research and
>> custom tools do make adoption more difficult.
>>
>> But to repeat my question, is updating the complier that difficult ? I
>> have not done any analysis , so I do not have a clue.
>> I plan to create a GUI driven build env for L4 to enable fine grain
>> customization and to be able to build
>> to specific resource constraints. As part of this effort, I can take a
>> stab at updating the compiler, if the
>> effort is not significant.
> 
> Thanks for getting back to us, we now have a better idea of what you
> are trying to do.
> 
> The kernel code is a restricted set of C++ with some assembly,
> while userland code is C with some assembly stubs.  As such
> most code should compile fine with a newer toolchain.  Having said that,
> we sometimes rely on more esoteric toolchain features such as alignment
> restrictions and linker scripts.  Sometimes things will trip because
> code which made assumptions which were valid is no longer valid for
> a newer toolchain, or maybe there is a genuine problem in the toolchain
> itself.
> 
> Note that if you specify the toolprefix= argument in the command line,
> it will prepend the value specified to gcc.  In this way you can
> specify an alternate path for your new toolchain for testing purposes.
> 
> 	-gl
> 
>>
>>
>> Madhu
>>
>>
>> Geoffrey Lee wrote:
>> >On Thu, May 08, 2008 at 06:37:45PM +0530, G S Madhusudan wrote:
>> >
>> >>Some apps I am testing do need the newer compilers. I guess multiple
>> >>versions of gcc
>> >>could be used but  it is easier to use a consistent toolchain. Any
>> >>particular reason why the migration to the newer is held up ? Is the
>> >>effort required that significant ?
>> >>
>> >>
>> >
>> >
>> >Hi
>> >
>> >Are these Linux applications or are these applications that you have
>> >ported to run natively on OKL4?
>> >
>> >A quick solution might be to compile out of tree and then stick
>> >them into the rootfs package or hard disk if you are booting
>> >off disk.  There is no real requirement for Linux applications
>> >run on OK Linux to be compiled with the pre-compiled toolchain,
>> >other than the fact that if they were dynamically linked they
>> >need to be compatible with the libc and related libraries that
>> >will be used to support the application on OK Linux.
>> >
>> >
>> >
>> >	-gl
>> >
>> >
>> >
>> >>Nelson Tam wrote:
>> >>
>> >>>Hi,
>> >>>
>> >>>On 08/05/2008, at 4:11 PM, G S Madhusudan wrote:
>> >>>
>> >>>>Is there any plan to shift to the latest versions of GCC  ?
>> >>>>
>> >>>At the moment, it's best if you could just stick to the recommended
>> >>>toolchains available at http://www.ertos.nicta.com.au/downloads.
>> >>>
>> >>>Are these tools causing a problem for you at the moment?
>> >>>--
>> >>>(nt)
>> >>>
>> >>>Nelson Tam
>> >>>
>> >>>
>> >>_______________________________________________
>> >>Developer mailing list
>> >>Developer at okl4.org
>> >>https://lists.okl4.org/mailman/listinfo/developer
>> >>
>> >>
>> >
>> >
>>
>>
> 
> --
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer




More information about the Developer mailing list