[llvmlinux] Quick build against stable versions of toolchain (llvm and clang) and Linux-kernel?

Tinti viniciustinti at gmail.com
Mon Jan 21 13:42:00 UTC 2013


>> Hi Sedat,
>>
>> I have reimplemented the checkpoint feature this weekend and I would
like to
>> test it with your settings too.
>>
>> Can you send me it? Also would be great to see other people trying to use
>> it. If you have time, please checkout my branch and read
>> Documentation/settings_file.txt.
>>
>
> We should stop top-posting, eh?

Yes. Thanks.

> With my (llvmlinux-patched) LLVM/CLANG toolchain I hit many
> non-toolchain issues this weekend when trying to build LIBDRM/MESA in
> an /opt/xorg installation.
>
> Following all daily upstream changes in LLVMLinux is NOT possible and
> NOT wanted by me.
>
> I think people are interested in "stable" work against stable releases.
>
> I was planning to push my adapted/refreshed LLVMLinux patches against
> v3.2-stable of llvm/clang/compiler-rt.
> Are you interested in them?

Yes. But I don't know where to place it. Maybe we could have stable work
and stable releases at the same time. Honestly, I don't know (even how).

> I had a look into your settings_file.txt file but did not get wiser,
sorry.
>
> I am still trying to track a Linux-Next issue with JBD2 (or LOOP).
> Let's see if linux-fsdevel people can help.
>
> Hope this helps you.

For sure it will.

Regards,
Tinti

- Sedat -


On Mon, Jan 21, 2013 at 10:39 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:

> On Mon, Jan 21, 2013 at 1:29 PM, Tinti <viniciustinti at gmail.com> wrote:
> > Hi Sedat,
> >
> > I have reimplemented the checkpoint feature this weekend and I would
> like to
> > test it with your settings too.
> >
> > Can you send me it? Also would be great to see other people trying to use
> > it. If you have time, please checkout my branch and read
> > Documentation/settings_file.txt.
> >
>
> We should stop top-posting, eh?
>
> With my (llvmlinux-patched) LLVM/CLANG toolchain I hit many
> non-toolchain issues this weekend when trying to build LIBDRM/MESA in
> an /opt/xorg installation.
>
> Following all daily upstream changes in LLVMLinux is NOT possible and
> NOT wanted by me.
>
> I think people are interested in "stable" work against stable releases.
>
> I was planning to push my adapted/refreshed LLVMLinux patches against
> v3.2-stable of llvm/clang/compiler-rt.
> Are you interested in them?
>
> I had a look into your settings_file.txt file but did not get wiser, sorry.
>
> I am still trying to track a Linux-Next issue with JBD2 (or LOOP).
> Let's see if linux-fsdevel people can help.
>
> Hope this helps you.
>
> - Sedat -
>
> > Best regards,
> > Tinti
> >
> >
> > On Thu, Jan 17, 2013 at 11:45 PM, Sedat Dilek <sedat.dilek at gmail.com>
> wrote:
> >>
> >> Hi Tinti,
> >>
> >> I have adapted the LLVM/CLANG patches from LLVMLinux project against
> >> v3.2-stable.
> >>
> >> Toolchain is fine...
> >> Just (mis)used build of mesa-8.x as a test-case [1].
> >>
> >> Will look tomorrow into the Linux x86_64 patches.
> >>
> >> - Sedat -
> >>
> >> [1]
> >>
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033614.html
> >>
> >> On Fri, Jan 18, 2013 at 2:35 AM, Tinti <viniciustinti at gmail.com> wrote:
> >> > Hi Sedat,
> >> >
> >> > About stable versions please check my branch. I have just uploaded the
> >> > documentation about it (Documentation/settings_file.txt) and an
> example
> >> > in
> >> > rpi target. I think it fits for your purposes.
> >> > I have not applied on master because I would like to have some reviews
> >> > and
> >> > feedbacks. Is anything else that you would like to add?
> >> >
> >> > Best regards,
> >> > Tinti
> >> >>
> >> >> What is {the | your | a good} base for the Linux-kernel (speaking of
> >> >> x86_64)?
> >> >> v3.7.y (latest stable version)?
> >> >
> >> > The LLVMLinux project works from the HEAD of LLVM and the Linux
> project.
> >> > Since the goal is to upstream patches to both projects, we really have
> >> > to
> >> > work from HEAD.
> >> >
> >> > As far as saving checkpoints that work with a particular version of a
> >> > kernel, somebody merely needs to create a settings file which details
> >> > the
> >> > versions of all SW involved. The settings file is described in
> >> > Documentation/settings_file.txt
> >> >
> >> > Tinti is using this to create a checkpoint for the rpi community so
> that
> >> > people can play with a stable kernel there for instance. You are
> welcome
> >> > to
> >> > do the same for x86_64.
> >> >
> >> >
> >> >
> >> > On Thu, Jan 17, 2013 at 2:53 PM, Behan Webster
> >> > <behanw at converseincode.com>
> >> > wrote:
> >> >>
> >> >> On 13-01-17 09:11 AM, Sedat Dilek wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> first of all I wish all people from the LLVMLinux project a happy
> new
> >> >>> year!
> >> >>
> >> >> Same to you! :)
> >> >>
> >> >>
> >> >>> After a case of death in my family I dropped all my OSS activities
> for
> >> >>> a
> >> >>> while.
> >> >>
> >> >> I'm very sorry to hear that.
> >> >>
> >> >>
> >> >>> The last weeks I started to build again mainline and Linux-Next
> >> >>> kernels.
> >> >>> ...and playing with Linux Test Project (LTP).
> >> >>> I would like also to test a llvmlinux-compiled Linux-kernel with
> LTP!
> >> >>
> >> >> We are already running LTP with a clang compiled kernel, but
> currently
> >> >> only for the vexpress (ARM based) kernel. It's just a matter of
> >> >> somebody
> >> >> porting the code. I too would like to see an automated x86 LTP test
> >> >> run.
> >> >>
> >> >>
> >> >>> Today, I remembered the $JOBS variable
> >> >>
> >> >> "make help" has details about a lot of things, including the $JOBS
> >> >> variable. The default value of JOBS likely will be close to optimum.
> On
> >> >> my
> >> >> machine (at least) if I ingrease JOBS much higher than the calculated
> >> >> default, it actually slows down the compile.
> >> >>
> >> >>
> >> >>> What is {the | your | a good} base for the Linux-kernel (speaking of
> >> >>> x86_64)?
> >> >>> v3.7.y (latest stable version)?
> >> >>
> >> >> The LLVMLinux project works from the HEAD of LLVM and the Linux
> >> >> project.
> >> >> Since the goal is to upstream patches to both projects, we really
> have
> >> >> to
> >> >> work from HEAD.
> >> >>
> >> >> As far as saving checkpoints that work with a particular version of a
> >> >> kernel, somebody merely needs to create a settings file which details
> >> >> the
> >> >> versions of all SW involved. The settings file is described in
> >> >> Documentation/settings_file.txt
> >> >>
> >> >> Tinti is using this to create a checkpoint for the rpi community so
> >> >> that
> >> >> people can play with a stable kernel there for instance. You are
> >> >> welcome to
> >> >> do the same for x86_64.
> >> >>
> >> >>
> >> >>> $ grep "Kernel Configuration" -nr ./
> >> >>> ./targets/x86_64/config_x86_64:3:# Linux/x86_64 3.7.0 Kernel
> >> >>> Configuration
> >> >>> ./targets/x86_64/config_x86_64_default:3:# Linux/x86_64 3.7.0-rc5
> >> >>> Kernel Configuration
> >> >>> ./targets/i586/config_i586:3:# Linux/x86_64 3.7.0 Kernel
> Configuration
> >> >>
> >> >> That's merely the version of the kernel that was being used when that
> >> >> config file was last updated. It doesn't indicate a stable version of
> >> >> the
> >> >> kernel source.
> >> >>
> >> >>
> >> >>> Is the listed kernel-config a good base?
> >> >>
> >> >> It is the one we are currently testing with. This file is intended to
> >> >> create a bootable kernel on an average x86_64 computer.
> >> >>
> >> >>
> >> >>> Same question to llvm and clang.
> >> >>> v3.2 (latest stable version)?
> >> >>
> >> >> Again, we don't use stable versions of the toolchain. We use HEAD.
> >> >> Until
> >> >> our patches are in we have to keep developing and testing with the
> >> >> latest/greatest code.
> >> >>
> >> >>
> >> >>> Personally, I wanted to test against ***stable*** versions of all 3
> >> >>> components.
> >> >>
> >> >> Great! That would be very helpful.
> >> >>
> >> >>
> >> >>> Some patches are not listed in the appropriate series files
> (so-to-say
> >> >>> UNUSED).
> >> >>
> >> >> The existence of a patch file doesn't mean it's actually being used.
> >> >> The
> >> >> series file lists which patches are currently in use.
> >> >>
> >> >> Patches which aren't in a series file usually are left in place until
> >> >> we're sure we don't need them anymore (or at all).
> >> >>
> >> >>
> >> >>> I am still against all this uncommon naming of patches (speaking
> >> >>> mostly of the ones for the Linux-kernel).
> >> >>
> >> >> In this case many of the patch names for x86_64 have been created
> from
> >> >> the
> >> >> commit comments by "git format-patch".
> >> >>
> >> >> I would encourage you to work within our build framework if you can.
> If
> >> >> we
> >> >> all work on the same code base, with the same test framework, we can
> >> >> much
> >> >> more easily share work and accelerate our efforts.
> >> >>
> >> >> Thanks!
> >> >>
> >> >> Behan
> >> >>
> >> >> --
> >> >> Behan Webster
> >> >> behanw at converseincode.com
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> LLVMLinux mailing list
> >> >> LLVMLinux at lists.linuxfoundation.org
> >> >> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Vinicius Tinti
> >> > mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
> >> > skype => {viniciustinti}
> >> >
> >> > _______________________________________________
> >> > LLVMLinux mailing list
> >> > LLVMLinux at lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
> >> _______________________________________________
> >> LLVMLinux mailing list
> >> LLVMLinux at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
> >
> >
> >
> >
> > --
> > Vinicius Tinti
> > mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
> > skype => {viniciustinti}
>



-- 
Vinicius Tinti
mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
skype => {viniciustinti}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130121/44a3376e/attachment.html>


More information about the LLVMLinux mailing list