<div dir="ltr">hi Aleksei,<div><br></div><div>i did an extra check for you, and found that Bear has no issues to run inside chroot. if you would call Bear outside of the chroot it will have the extra path element to your chroot... (it is still produce a usable output, although some post processing would be required. :))</div>
<div><br></div><div>i don't know how would you use osc. and how would you run the analyzer/scan-build with osc... if i were you, i might create compilation databases with rpmbuild macros (produced by cmake or Bear). and use that to run scan-build or any other clang based tool. (maybe those could be also rpmbuild macros as well.)</div>
<div><br></div><div>regards,</div><div>Laszlo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 12:26 PM, Aleksei Sidorin <span dir="ltr"><<a href="mailto:a.sidorin@samsung.com" target="_blank">a.sidorin@samsung.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Hello Laszlo,<br>
      <br>
      Thanks, that is interesting.<br>
      I read this in Bear description:<br>
      "The concept behind Bear is to exec the original build command and
      intercept the <code>exec</code> calls of the build tool. To
      achive that Bear uses the
      <code>LD_PRELOAD</code> or <code>DYLD_INSERT_LIBRARIES</code>
      mechanisms provided by the dynamic
      linker."<br>
      <br>
      I tried to escape this approach because it can face some problems
      with emulator-based build systems. For example, it can cause
      conflicts of build and interceptor architectures and there may be
      incorrect paths after chroot. If you are familiar with this tool,
      can you check it for correct work with chroot build environments
      (like osc:
      <a href="http://en.opensuse.org/openSUSE:Build_Service_Tutorial" target="_blank">http://en.opensuse.org/openSUSE:Build_Service_Tutorial</a>)? As I
      understand from description, it may have some problems with
      emulator-based build systems.<br>
      <br>
      <br>
      <br>
      15.05.2014 12:11, Laszlo Nagy пишет:<br>
    </div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">Interesting approach you have showed Aleksei. I had
        a similar problem, but approached it differently... I wrote a
        program which intercept the compiler calls and generate a
        compilation database. (you can generate it from cmake files)
        That tool is called <a href="https://github.com/rizsotto/Bear" target="_blank">bear</a>,
        and it works on linux/FreeBSD/OS X as well... And with the
        rewrite of scan-build wanted to extend the current functionality
        to use the compilation database (beside to work with the current
        environment based approach)... At this moment I still work on
        the ccc-analyzer implementation in python... Алексей Климов and
        Sylvestre Ledru in the frame of a GSoC also wanted to rewrite
        the scan-build part.</div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, May 13, 2014 at 6:01 PM, Jordan
          Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[+cfe-commits
            again, -cfe-dev]<br>
            <br>
            Interested yes, but unfortunately not all of the people
            involved in the analyzer are using Linux systems. (I'm on OS
            X.) I've CC'd a few other recent contributors to the
            analyzer, but I can't remember if they are familiar with and
            have access to Linux systems either. (Laszlo in particular
            is attempting to rewrite scan-build in Python, for more
            uniformity with the rest of LLVM, so this is the sort of
            thing he'd want to stay up-to-date about.)<br>
            <br>
            Sorry for not being so responsive here,<br>
            Jordan<br>
            <div>
              <div><br>
                <br>
                On May 13, 2014, at 8:47 , Aleksei Sidorin <<a href="mailto:a.sidorin@samsung.com" target="_blank">a.sidorin@samsung.com</a>>
                wrote:<br>
                <br>
                > Hello again,<br>
                ><br>
                > I sent a message to cfe-commits mailing list, but
                nobody answered. This task is listed in open projects.
                Is anybody interested in this interceptor?<br>
                ><br>
                > Link to review: <a href="http://reviews.llvm.org/D3608" target="_blank">http://reviews.llvm.org/D3608</a><br>
                ><br>
                > 29.04.2014 09:38, Aleksei Sidorin:<br>
                >> Hello,<br>
                >><br>
                >> This patch enables interception of compiler
                calls without replacement of environment variables. It
                uses strace (v.4.8) to compute root directory of
                processes (in case of chroot), working directory,
                process name and its environment variables and tries to
                guess some header directories. This approach works well
                with Android and some build systems like OBS (local
                build with osc client) and GBS (checked on Tizen). This
                behaviour can be enabled with --use-interceptor option.
                If this option is not specified, old behaviour is used
                (this patch was made to not break it).<br>
                >><br>
                >> Interceptor uses process pool to analyze
                multiple files at a time. Pool size can be specified
                with NUM_PROCESSES environment variable. Default pool
                size is a number of processors.<br>
                >><br>
                >> If we have a trace of build (that may be
                created with `strace -f -v -s 1000000 -o
                $trace_file_name -e
                trace=vfork,fork,clone,execve,chdir,chroot -e signal=
                $build_cmd`), it can be passed via TRACE_FILE
                environment variable. This will not launch parallel
                build (analysis only). If option is not specified,
                temporary pipe is used, analyzer and compiler are
                executed in parallel.<br>
                >><br>
                >> -additional-arg option was also added to pass
                additional parameters to analyzer. Sometimes scan-build
                cannot determine all required parameters if some custom
                toolchain is used.<br>
                >><br>
                >> Interceptor was tested on Ubuntu 12.04 and
                14.04 with strace 4.8. Strace v.4.6 is known to have
                some issues with interception of gcc.<br>
                >><br>
                ><br>
                ><br>
                > --<br>
                > Best regards,<br>
                > Aleksei Sidorin<br>
                > Software Engineer,<br>
                > IMSWL-IMCG, SRR, Samsung Electronics<br>
                ><br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 
Best regards,
Aleksei Sidorin
Software Engineer, 
IMSWL-IMCG, SRR, Samsung Electronics
</pre>
  </div></div></div>

</blockquote></div><br></div>