Re: uapi headers userspace build results
Hi Randy, Apologies for not keeping everyone up to date on this. A couple of colleagues (cc'ed): Tri and Matthias, are going to be taking over this work. Thanks, Jayant On 5/27/19 3:12 PM, Randy Dunlap wrote: > Hi Jayant, > > What ever happened to this script and subsequent patches? > > thanks. > > On 6/19/18 11:17 AM, Randy Dunlap wrote: >> On 06/18/2018 06:47 PM, Jayant Chowdhary wrote: >>> Hi Randy, >>> >>> On 06/12/2018 05:07 PM, Randy Dunlap wrote: On 06/12/2018 01:39 PM, Jayant Chowdhary wrote: > Hi Randy, > > On 06/11/2018 10:49 PM, Randy Dunlap wrote: >> Hi, >> >> Here is what I have so far. It begins with a makefile and some >> template files that are added to. There's a good bit of Perl also. >> >> I put all of these files in tools/uapi/ and run them from there. >> >> There is one .c file generated for each .h file in builddir/usr/include >> (O=builddir). >> > > Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put > in > tools/build (I can change this to tools/uapi, if that is more apt). Your makefile foo is much better than mine is. Yes, I think that it deserves to be in its own sub-directory. > uapi-compile.mk straight-away compiles the uapi headers, without pulling > them > into any generated c source files. It may also be invoked with an > environment Hm, I didn't even know that is possible. > variable 'UAPI_DIR' specifying the directory, for which the user would > like to > compile headers. This way we can test a directory at a time as well. In > your Yes, good, I was planning to make a way to restrict the build to certain sub-dirs. > opinion, would this be simpler to have rather than having to > auto-generate c > source files including each uapi header and also autog-enerating the make > targets? I feel like this approach would make maintaining these makefiles/ > scripts easier as well. Sure, this is much better than my scripts. >> Out of 889 header files, I see 45 errors. That is better than I >> expected. >> >> The makefiles and scripts are attached (tar), as well as the output (I >> used >> 'make -ik' so that make would keep going after errors and attempt to >> build >> all target files). >> >> have fun! >> > > I did a 'make ARCH=arm64 headers_install' from the kernel source's root, > and > then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the > headers. Out of 864 headers, I see 20 compilation failures. > > I'm attaching uapi-compile.mk and the build.log file along. I have some usage comments. Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify uapi-compile.mk to use that SRC_DIR: SRC_DIR :=../../xx64 Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and uapi-compile.mk did not work (when using BDIR=BDIR). Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and that worked. But: that sub-dir is not used: gcc -I../../xx64/usr/include/ --include=../../xx64/usr/include/linux/posix_types.h --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h --include=stdint.h --include=stddef.h -c ../../xx64/usr/include//linux/caif/caif_socket.h -o ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o [see the next comment] Oh, this makefile builds the .o files in the same sub-dirs as their respective .h files. I don't especially like that, but as long as make clean works, it will do. [and make clean does work] >>> >>> Thanks for these comments. I'll take care of them in my patch-set. I've got >>> a >>> couple of questions for you. Since most of the errors were found in the >>> include/uapi/linux directory, I tried investigating why. >> >> Please also repost your latest patch-set. >> >>> 1) I found that multiple headers depend on the definition of types such as >>> pid_t, which have no definition in the set of uapi headers. There is a >>> definition (of pid_t) in include/linux/types.h, and I thought we could try >>> exposing that in the set of uapi headers. One problem I can see with that is >>> that the header has some definitions which depend on kernel configs: eg: >>> CONFIG_ARCH_DMA_ADDR_T_64BIT. Since user-land programs shouldn't really >>> assume >>> kernel configs, I was thinking we should re-factor this header so that >>> appropriate parts can be exposed to user-land. >> >> Sure, that's worth a try. Mostly on a case-by-case basis. >> >> I see that (at least in the distro that I am using) >> /usr/include/asm-generic/posix_types.h has a typedef for __kernel_pid_t. >> I wonder if that could be co-opted, but I expect that this would have >> type/size issues. >> >>
Re: uapi headers userspace build results
Hi Jayant, What ever happened to this script and subsequent patches? thanks. On 6/19/18 11:17 AM, Randy Dunlap wrote: > On 06/18/2018 06:47 PM, Jayant Chowdhary wrote: >> Hi Randy, >> >> On 06/12/2018 05:07 PM, Randy Dunlap wrote: >>> On 06/12/2018 01:39 PM, Jayant Chowdhary wrote: Hi Randy, On 06/11/2018 10:49 PM, Randy Dunlap wrote: > Hi, > > Here is what I have so far. It begins with a makefile and some > template files that are added to. There's a good bit of Perl also. > > I put all of these files in tools/uapi/ and run them from there. > > There is one .c file generated for each .h file in builddir/usr/include > (O=builddir). > Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put in tools/build (I can change this to tools/uapi, if that is more apt). >>> >>> Your makefile foo is much better than mine is. >>> Yes, I think that it deserves to be in its own sub-directory. >>> uapi-compile.mk straight-away compiles the uapi headers, without pulling them into any generated c source files. It may also be invoked with an environment >>> >>> Hm, I didn't even know that is possible. >>> variable 'UAPI_DIR' specifying the directory, for which the user would like to compile headers. This way we can test a directory at a time as well. In your >>> >>> Yes, good, I was planning to make a way to restrict the build to certain >>> sub-dirs. >>> opinion, would this be simpler to have rather than having to auto-generate c source files including each uapi header and also autog-enerating the make targets? I feel like this approach would make maintaining these makefiles/ scripts easier as well. >>> >>> Sure, this is much better than my scripts. >>> > Out of 889 header files, I see 45 errors. That is better than I expected. > > The makefiles and scripts are attached (tar), as well as the output (I > used > 'make -ik' so that make would keep going after errors and attempt to build > all target files). > > have fun! > I did a 'make ARCH=arm64 headers_install' from the kernel source's root, and then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the headers. Out of 864 headers, I see 20 compilation failures. I'm attaching uapi-compile.mk and the build.log file along. >>> >>> I have some usage comments. >>> >>> Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify >>> uapi-compile.mk to use that SRC_DIR: >>> >>> SRC_DIR :=../../xx64 >>> >>> Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and >>> uapi-compile.mk did not work (when using BDIR=BDIR). >>> Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and >>> that worked. But: that sub-dir is not used: >>> >>> gcc -I../../xx64/usr/include/ >>> --include=../../xx64/usr/include/linux/posix_types.h >>> --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h >>> --include=stdint.h --include=stddef.h -c >>> ../../xx64/usr/include//linux/caif/caif_socket.h -o >>> ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o >>> [see the next comment] >>> >>> Oh, this makefile builds the .o files in the same sub-dirs as their >>> respective .h files. I don't especially like that, but as long as >>> make clean works, it will do. [and make clean does work] >>> >> >> Thanks for these comments. I'll take care of them in my patch-set. I've got a >> couple of questions for you. Since most of the errors were found in the >> include/uapi/linux directory, I tried investigating why. > > Please also repost your latest patch-set. > >> 1) I found that multiple headers depend on the definition of types such as >> pid_t, which have no definition in the set of uapi headers. There is a >> definition (of pid_t) in include/linux/types.h, and I thought we could try >> exposing that in the set of uapi headers. One problem I can see with that is >> that the header has some definitions which depend on kernel configs: eg: >> CONFIG_ARCH_DMA_ADDR_T_64BIT. Since user-land programs shouldn't really >> assume >> kernel configs, I was thinking we should re-factor this header so that >> appropriate parts can be exposed to user-land. > > Sure, that's worth a try. Mostly on a case-by-case basis. > > I see that (at least in the distro that I am using) > /usr/include/asm-generic/posix_types.h has a typedef for __kernel_pid_t. > I wonder if that could be co-opted, but I expect that this would have > type/size issues. > > OTOH, 'man getpid' uses pid_t and refers to and , > so there should already be a pid_t for userspace. Just #include more > headers files. :) > >> 2) Some headers try to expose information which should probably not be >> exposed >> to user-land. eg: wait_queue_head in linux/coda_psdev.h (this header should >> probably be removed altogether ?) > > I
Re: uapi headers userspace build results
On 06/18/2018 06:47 PM, Jayant Chowdhary wrote:
> Hi Randy,
>
> On 06/12/2018 05:07 PM, Randy Dunlap wrote:
>> On 06/12/2018 01:39 PM, Jayant Chowdhary wrote:
>>> Hi Randy,
>>>
>>> On 06/11/2018 10:49 PM, Randy Dunlap wrote:
Hi,
Here is what I have so far. It begins with a makefile and some
template files that are added to. There's a good bit of Perl also.
I put all of these files in tools/uapi/ and run them from there.
There is one .c file generated for each .h file in builddir/usr/include
(O=builddir).
>>>
>>> Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put in
>>> tools/build (I can change this to tools/uapi, if that is more apt).
>>
>> Your makefile foo is much better than mine is.
>> Yes, I think that it deserves to be in its own sub-directory.
>>
>>> uapi-compile.mk straight-away compiles the uapi headers, without pulling
>>> them
>>> into any generated c source files. It may also be invoked with an
>>> environment
>>
>> Hm, I didn't even know that is possible.
>>
>>> variable 'UAPI_DIR' specifying the directory, for which the user would like
>>> to
>>> compile headers. This way we can test a directory at a time as well. In your
>>
>> Yes, good, I was planning to make a way to restrict the build to certain
>> sub-dirs.
>>
>>> opinion, would this be simpler to have rather than having to auto-generate c
>>> source files including each uapi header and also autog-enerating the make
>>> targets? I feel like this approach would make maintaining these makefiles/
>>> scripts easier as well.
>>
>> Sure, this is much better than my scripts.
>>
Out of 889 header files, I see 45 errors. That is better than I expected.
The makefiles and scripts are attached (tar), as well as the output (I used
'make -ik' so that make would keep going after errors and attempt to build
all target files).
have fun!
>>>
>>> I did a 'make ARCH=arm64 headers_install' from the kernel source's root, and
>>> then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the
>>> headers. Out of 864 headers, I see 20 compilation failures.
>>>
>>> I'm attaching uapi-compile.mk and the build.log file along.
>>
>> I have some usage comments.
>>
>> Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify
>> uapi-compile.mk to use that SRC_DIR:
>>
>> SRC_DIR :=../../xx64
>>
>> Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and
>> uapi-compile.mk did not work (when using BDIR=BDIR).
>> Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and
>> that worked. But: that sub-dir is not used:
>>
>> gcc -I../../xx64/usr/include/
>> --include=../../xx64/usr/include/linux/posix_types.h
>> --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h
>> --include=stdint.h --include=stddef.h -c
>> ../../xx64/usr/include//linux/caif/caif_socket.h -o
>> ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o
>> [see the next comment]
>>
>> Oh, this makefile builds the .o files in the same sub-dirs as their
>> respective .h files. I don't especially like that, but as long as
>> make clean works, it will do. [and make clean does work]
>>
>
> Thanks for these comments. I'll take care of them in my patch-set. I've got a
> couple of questions for you. Since most of the errors were found in the
> include/uapi/linux directory, I tried investigating why.
Please also repost your latest patch-set.
> 1) I found that multiple headers depend on the definition of types such as
> pid_t, which have no definition in the set of uapi headers. There is a
> definition (of pid_t) in include/linux/types.h, and I thought we could try
> exposing that in the set of uapi headers. One problem I can see with that is
> that the header has some definitions which depend on kernel configs: eg:
> CONFIG_ARCH_DMA_ADDR_T_64BIT. Since user-land programs shouldn't really assume
> kernel configs, I was thinking we should re-factor this header so that
> appropriate parts can be exposed to user-land.
Sure, that's worth a try. Mostly on a case-by-case basis.
I see that (at least in the distro that I am using)
/usr/include/asm-generic/posix_types.h has a typedef for __kernel_pid_t.
I wonder if that could be co-opted, but I expect that this would have
type/size issues.
OTOH, 'man getpid' uses pid_t and refers to and ,
so there should already be a pid_t for userspace. Just #include more
headers files. :)
> 2) Some headers try to expose information which should probably not be exposed
> to user-land. eg: wait_queue_head in linux/coda_psdev.h (this header should
> probably be removed altogether ?)
I suppose that header file describes a kernel-to-userspace ("Venus") interface,
so maybe not removed altogether. But the wait_queue_head_t part of it should
just be some padding/reserved field (of what size/type?).
> Do you have better ideas ?
slow and steady.
--
~Randy
Re: uapi headers userspace build results
Hi Randy, On 06/12/2018 05:07 PM, Randy Dunlap wrote: > On 06/12/2018 01:39 PM, Jayant Chowdhary wrote: >> Hi Randy, >> >> On 06/11/2018 10:49 PM, Randy Dunlap wrote: >>> Hi, >>> >>> Here is what I have so far. It begins with a makefile and some >>> template files that are added to. There's a good bit of Perl also. >>> >>> I put all of these files in tools/uapi/ and run them from there. >>> >>> There is one .c file generated for each .h file in builddir/usr/include >>> (O=builddir). >>> >> >> Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put in >> tools/build (I can change this to tools/uapi, if that is more apt). > > Your makefile foo is much better than mine is. > Yes, I think that it deserves to be in its own sub-directory. > >> uapi-compile.mk straight-away compiles the uapi headers, without pulling them >> into any generated c source files. It may also be invoked with an environment > > Hm, I didn't even know that is possible. > >> variable 'UAPI_DIR' specifying the directory, for which the user would like >> to >> compile headers. This way we can test a directory at a time as well. In your > > Yes, good, I was planning to make a way to restrict the build to certain > sub-dirs. > >> opinion, would this be simpler to have rather than having to auto-generate c >> source files including each uapi header and also autog-enerating the make >> targets? I feel like this approach would make maintaining these makefiles/ >> scripts easier as well. > > Sure, this is much better than my scripts. > >>> Out of 889 header files, I see 45 errors. That is better than I expected. >>> >>> The makefiles and scripts are attached (tar), as well as the output (I used >>> 'make -ik' so that make would keep going after errors and attempt to build >>> all target files). >>> >>> have fun! >>> >> >> I did a 'make ARCH=arm64 headers_install' from the kernel source's root, and >> then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the >> headers. Out of 864 headers, I see 20 compilation failures. >> >> I'm attaching uapi-compile.mk and the build.log file along. > > I have some usage comments. > > Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify > uapi-compile.mk to use that SRC_DIR: > > SRC_DIR :=../../xx64 > > Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and > uapi-compile.mk did not work (when using BDIR=BDIR). > Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and > that worked. But: that sub-dir is not used: > > gcc -I../../xx64/usr/include/ > --include=../../xx64/usr/include/linux/posix_types.h > --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h > --include=stdint.h --include=stddef.h -c > ../../xx64/usr/include//linux/caif/caif_socket.h -o > ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o > [see the next comment] > > Oh, this makefile builds the .o files in the same sub-dirs as their > respective .h files. I don't especially like that, but as long as > make clean works, it will do. [and make clean does work] > Thanks for these comments. I'll take care of them in my patch-set. I've got a couple of questions for you. Since most of the errors were found in the include/uapi/linux directory, I tried investigating why. 1) I found that multiple headers depend on the definition of types such as pid_t, which have no definition in the set of uapi headers. There is a definition (of pid_t) in include/linux/types.h, and I thought we could try exposing that in the set of uapi headers. One problem I can see with that is that the header has some definitions which depend on kernel configs: eg: CONFIG_ARCH_DMA_ADDR_T_64BIT. Since user-land programs shouldn't really assume kernel configs, I was thinking we should re-factor this header so that appropriate parts can be exposed to user-land. 2) Some headers try to expose information which should probably not be exposed to user-land. eg: wait_queue_head in linux/coda_psdev.h (this header should probably be removed altogether ?) Do you have better ideas ? Thanks, Jayant > Thanks. >
Re: uapi headers userspace build results
On 06/12/2018 01:39 PM, Jayant Chowdhary wrote: > Hi Randy, > > On 06/11/2018 10:49 PM, Randy Dunlap wrote: >> Hi, >> >> Here is what I have so far. It begins with a makefile and some >> template files that are added to. There's a good bit of Perl also. >> >> I put all of these files in tools/uapi/ and run them from there. >> >> There is one .c file generated for each .h file in builddir/usr/include >> (O=builddir). >> > > Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put in > tools/build (I can change this to tools/uapi, if that is more apt). Your makefile foo is much better than mine is. Yes, I think that it deserves to be in its own sub-directory. > uapi-compile.mk straight-away compiles the uapi headers, without pulling them > into any generated c source files. It may also be invoked with an environment Hm, I didn't even know that is possible. > variable 'UAPI_DIR' specifying the directory, for which the user would like to > compile headers. This way we can test a directory at a time as well. In your Yes, good, I was planning to make a way to restrict the build to certain sub-dirs. > opinion, would this be simpler to have rather than having to auto-generate c > source files including each uapi header and also autog-enerating the make > targets? I feel like this approach would make maintaining these makefiles/ > scripts easier as well. Sure, this is much better than my scripts. >> Out of 889 header files, I see 45 errors. That is better than I expected. >> >> The makefiles and scripts are attached (tar), as well as the output (I used >> 'make -ik' so that make would keep going after errors and attempt to build >> all target files). >> >> have fun! >> > > I did a 'make ARCH=arm64 headers_install' from the kernel source's root, and > then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the > headers. Out of 864 headers, I see 20 compilation failures. > > I'm attaching uapi-compile.mk and the build.log file along. I have some usage comments. Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify uapi-compile.mk to use that SRC_DIR: SRC_DIR :=../../xx64 Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and uapi-compile.mk did not work (when using BDIR=BDIR). Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and that worked. But: that sub-dir is not used: gcc -I../../xx64/usr/include/ --include=../../xx64/usr/include/linux/posix_types.h --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h --include=stdint.h --include=stddef.h -c ../../xx64/usr/include//linux/caif/caif_socket.h -o ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o [see the next comment] Oh, this makefile builds the .o files in the same sub-dirs as their respective .h files. I don't especially like that, but as long as make clean works, it will do. [and make clean does work] Thanks. -- ~Randy
uapi headers userspace build results
Hi, Here is what I have so far. It begins with a makefile and some template files that are added to. There's a good bit of Perl also. I put all of these files in tools/uapi/ and run them from there. There is one .c file generated for each .h file in builddir/usr/include (O=builddir). Out of 889 header files, I see 45 errors. That is better than I expected. The makefiles and scripts are attached (tar), as well as the output (I used 'make -ik' so that make would keep going after errors and attempt to build all target files). have fun! -- ~Randy gcc "-I../../xx64/usr/include" -c -o drm.i810_drm.o drm.i810_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm_fourcc.o drm.drm_fourcc.c gcc "-I../../xx64/usr/include" -c -o drm.etnaviv_drm.o drm.etnaviv_drm.c gcc "-I../../xx64/usr/include" -c -o drm.i915_drm.o drm.i915_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm_mode.o drm.drm_mode.c gcc "-I../../xx64/usr/include" -c -o drm.vc4_drm.o drm.vc4_drm.c gcc "-I../../xx64/usr/include" -c -o drm.mga_drm.o drm.mga_drm.c gcc "-I../../xx64/usr/include" -c -o drm.v3d_drm.o drm.v3d_drm.c gcc "-I../../xx64/usr/include" -c -o drm.msm_drm.o drm.msm_drm.c gcc "-I../../xx64/usr/include" -c -o drm.amdgpu_drm.o drm.amdgpu_drm.c gcc "-I../../xx64/usr/include" -c -o drm.exynos_drm.o drm.exynos_drm.c gcc "-I../../xx64/usr/include" -c -o drm.sis_drm.o drm.sis_drm.c gcc "-I../../xx64/usr/include" -c -o drm.armada_drm.o drm.armada_drm.c gcc "-I../../xx64/usr/include" -c -o drm.savage_drm.o drm.savage_drm.c gcc "-I../../xx64/usr/include" -c -o drm.r128_drm.o drm.r128_drm.c gcc "-I../../xx64/usr/include" -c -o drm.qxl_drm.o drm.qxl_drm.c gcc "-I../../xx64/usr/include" -c -o drm.vmwgfx_drm.o drm.vmwgfx_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm_sarea.o drm.drm_sarea.c gcc "-I../../xx64/usr/include" -c -o drm.via_drm.o drm.via_drm.c gcc "-I../../xx64/usr/include" -c -o drm.tegra_drm.o drm.tegra_drm.c gcc "-I../../xx64/usr/include" -c -o drm.omap_drm.o drm.omap_drm.c gcc "-I../../xx64/usr/include" -c -o drm.radeon_drm.o drm.radeon_drm.c gcc "-I../../xx64/usr/include" -c -o drm.virtgpu_drm.o drm.virtgpu_drm.c gcc "-I../../xx64/usr/include" -c -o drm.vgem_drm.o drm.vgem_drm.c gcc "-I../../xx64/usr/include" -c -o drm.nouveau_drm.o drm.nouveau_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm.o drm.drm.c gcc "-I../../xx64/usr/include" -c -o mtd.mtd-user.o mtd.mtd-user.c gcc "-I../../xx64/usr/include" -c -o mtd.ubi-user.o mtd.ubi-user.c gcc "-I../../xx64/usr/include" -c -o mtd.nftl-user.o mtd.nftl-user.c gcc "-I../../xx64/usr/include" -c -o mtd.mtd-abi.o mtd.mtd-abi.c gcc "-I../../xx64/usr/include" -c -o mtd.inftl-user.o mtd.inftl-user.c gcc "-I../../xx64/usr/include" -c -o sound.emu10k1.o sound.emu10k1.c gcc "-I../../xx64/usr/include" -c -o sound.sb16_csp.o sound.sb16_csp.c gcc "-I../../xx64/usr/include" -c -o sound.firewire.o sound.firewire.c gcc "-I../../xx64/usr/include" -c -o sound.asound_fm.o sound.asound_fm.c gcc "-I../../xx64/usr/include" -c -o sound.usb_stream.o sound.usb_stream.c gcc "-I../../xx64/usr/include" -c -o sound.compress_params.o sound.compress_params.c gcc "-I../../xx64/usr/include" -c -o sound.asoc.o sound.asoc.c gcc "-I../../xx64/usr/include" -c -o sound.sfnt_info.o sound.sfnt_info.c gcc "-I../../xx64/usr/include" -c -o sound.snd_sst_tokens.o sound.snd_sst_tokens.c gcc "-I../../xx64/usr/include" -c -o sound.compress_offload.o sound.compress_offload.c gcc "-I../../xx64/usr/include" -c -o sound.asequencer.o sound.asequencer.c gcc "-I../../xx64/usr/include" -c -o sound.hdspm.o sound.hdspm.c gcc "-I../../xx64/usr/include" -c -o sound.tlv.o sound.tlv.c gcc "-I../../xx64/usr/include" -c -o sound.asound.o sound.asound.c gcc "-I../../xx64/usr/include" -c -o sound.hdsp.o sound.hdsp.c gcc "-I../../xx64/usr/include" -c -o rdma.mlx5_user_ioctl_verbs.o rdma.mlx5_user_ioctl_verbs.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_mad.o rdma.ib_user_mad.c gcc "-I../../xx64/usr/include" -c -o rdma.rdma_user_rxe.o rdma.rdma_user_rxe.c gcc "-I../../xx64/usr/include" -c -o rdma.ocrdma-abi.o rdma.ocrdma-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_cm.o rdma.ib_user_cm.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_ioctl_cmds.o rdma.ib_user_ioctl_cmds.c gcc "-I../../xx64/usr/include" -c -o rdma.i40iw-abi.o rdma.i40iw-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.rdma_netlink.o rdma.rdma_netlink.c gcc "-I../../xx64/usr/include" -c -o rdma.cxgb4-abi.o rdma.cxgb4-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_sa.o rdma.ib_user_sa.c gcc "-I../../xx64/usr/include" -c -o rdma.hns-abi.o rdma.hns-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.rdma_user_cm.o rdma.rdma_user_cm.c gcc "-I../../xx64/usr/include" -c -o rdma.bnxt_re-abi.o rdma.bnxt_re-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.mthca-abi.o rdma.mthca-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.qedr-abi.o rdma.qedr-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.mlx5_use
