[oi-dev] gfx-drm build issue

Jim Klimov jimklimov at cos.ru
Sun Jan 1 15:11:56 UTC 2017

31 декабря 2016 г. 20:22:38 CET, Jim Klimov <jim at cos.ru> пишет:
>31 декабря 2016 г. 17:56:49 CET, Gordon Ross <gordon.w.ross at gmail.com>
>>I understand that (most of) userland wants to use some recent
>>However, the kernel components in drm _really_ need to use the
>>that supports mdb and dtrace (no frameless calls etc.)
>>So if there's an override of CC, we need that to _not_ happen
>>for the specific case of building gfx-drm under userland.
>>On Sat, Dec 31, 2016 at 3:17 AM, Jim Klimov <jimklimov at cos.ru> wrote:
>>> 31 декабря 2016 г. 6:23:31 CET, Gordon Ross
><gordon.w.ross at gmail.com>
>>>>Should be:  /opt/gcc/4.4.4/bin/gcc
>>>>I wonder if the build under oi-userland overrides $CC somehow?
>>>>On Fri, Dec 30, 2016 at 11:43 PM, Gordon Ross
>><gordon.w.ross at gmail.com>
>>>>> Hi Alexander,
>>>>> No, I did not see that warning.  What compiler was in use?
>>>>> On Tue, Dec 27, 2016 at 7:21 AM, Alexander Pyhalov <alp at rsu.ru>
>>>>>> Hi. Do you see this?
>>>>>>  /opt/onbld/bin/bldenv myenv.sh 'cd usr/src;  make'
>>>>>> ../../intel/io/agpgart/agpgart.c: In function 'agp_devmap_unmap':
>>>>>> ../../intel/io/agpgart/agpgart.c:152: error: 'mementry' may be
>>>>>> uninitialized in this function [-Wuninitialized]
>>>>>> And compiler is correct. The following seems to fix this warning:
>>>>>> diff --git a/usr/src/uts/intel/io/agpgart/agpgart.c
>>>>>> b/usr/src/uts/intel/io/agpgart/agpgart.c
>>>>>> index 34f5ca5..b1d6263 100644
>>>>>> --- a/usr/src/uts/intel/io/agpgart/agpgart.c
>>>>>> +++ b/usr/src/uts/intel/io/agpgart/agpgart.c
>>>>>> @@ -149,7 +149,7 @@ agp_devmap_unmap(devmap_cookie_t handle, void
>>>>>> *devprivate,
>>>>>>      void **new_devprivate2)
>>>>>>  {
>>>>>> -       struct keytable_ent *mementry;
>>>>>> +       struct keytable_ent *mementry = NULL;
>>>>>>         agpgart_softstate_t *softstate;
>>>>>>         agpgart_ctx_t *ctxp, *newctxp1, *newctxp2;
>>>>>> @@ -187,6 +187,7 @@ agp_devmap_unmap(devmap_cookie_t handle, void
>>>>>> *devprivate,
>>>>>>                 ASSERT(mementry);
>>>>>>                 mementry->kte_refcnt++;
>>>>>>         }
>>>>>> +       ASSERT(mementry != NULL);
>>>>>>         ASSERT(mementry->kte_refcnt >= 0);
>>>>>>         mutex_exit(&softstate->asoft_instmutex);
>>>>>>         kmem_free(ctxp, sizeof (struct agpgart_ctx));
>>>>>> --
>>>>>> С уважением,
>>>>>> Александр Пыхалов,
>>>>>> программист отдела телекоммуникационной инфраструктуры
>>>>>> управления информационно-коммуникационной инфраструктуры ЮФУ
>>>>oi-dev mailing list
>>>>oi-dev at openindiana.org
>>> By defaults of the past year or so, CC and CXX in oi-userland should
>>point to a wrapper-script from tools/ that calls CCACHE (if available)
>>and wraps the previously set default GCC compiler of the userland
>>makefile framework. I wish that a less clumsy solution were possible
>>(for less forking), but others I tried with vanilla ccache did not
>>well to pass into sub-builds launched by the recipes. If ccache is not
>>available (or is disabled with its toggle envvars), original compiler
>>vars are used unchanged by the makefiles.
>>> Also, afaik the userland is built with gcc-4.9 (or 4.8?), not with
>>the os/net 4.4.4-il.
>>> Jim
>>> --
>>> Typos courtesy of K-9 Mail on my Samsung Android
>FWIW, we can wrap illumos-gate gcc-4.4.4-il by ccache just as well. I
>have yet to finish and try to integrate this cleanly (does save about
>2x the time in make debug and nd builds), but can for now suffice to
>say it works. So ccache is not an issue here. Making the recipe build
>with 4.4.4-il (perhaps including the envvars that ccache wrapping for
>our userland uses) may be indeed the point for this issue.
>Happy New Year,
>this may well be my last post from the past 2016,
>Jim Klimov
>Typos courtesy of K-9 Mail on my Samsung Android
>oi-dev mailing list
>oi-dev at openindiana.org

By the way, regarding builds of illumos-gate, I estimate that most of the time is spent walking the makefiles and directories, several rounds while nightly.sh works. On lesser computers this alone adds up to tens of minutes if not hours.

Are there any hints or efforts on optimising this? Maybe somehow precompile a single big makefile to reduce walks and forks, or something?
Typos courtesy of K-9 Mail on my Samsung Android

More information about the oi-dev mailing list