Hi, Is it possible to link native codes generated by different compiler? the usecase could be: Linux kernel compiled by gcc want to load kernel module compiled by Clang (I know there have some problem to compile kernel by Clang currently, but ignore those problem in here) I just concern about the call conversion problem, and compatibility between gcc and clang. Thanks .jovi
Hi Jovi,> Is it possible to link native codes generated by different compiler?It should be. Clang aims to be GCC-compatible (and certainly in ABI issues on a given platform like Linux). Any issues would be considered bugs and we'd like to know about them. Cheers. Tim.
On Fri, May 3, 2013 at 11:17 PM, Tim Northover <t.p.northover at gmail.com> wrote:> Hi Jovi, > >> Is it possible to link native codes generated by different compiler? > > It should be. Clang aims to be GCC-compatible (and certainly in ABI > issues on a given platform like Linux). Any issues would be considered > bugs and we'd like to know about them. > > Cheers. > > Tim.Thanks Tim, I got it now.
On Fri, May 03, 2013 at 11:11:30PM +0800, Jovi Zhang wrote:> Hi, > > Is it possible to link native codes generated by different compiler? > > the usecase could be: > Linux kernel compiled by gcc want to load kernel module compiled by Clang > (I know there have some problem to compile kernel by Clang currently, > but ignore those problem in here) > > I just concern about the call conversion problem, and compatibility > between gcc and clang.Hi Jovi, It can be complicated. Many distributions patch gcc, the kernel, and the entire tool chain. A good example is RedHat, which applies many many patches to the kernel and the tool chain, including gcc. I believe embedded releases are similar. The canonical kernel releases are only tested on specific canonical versions of gcc. While I am certain you can realize this goal, you might run into some subtle problems. I would start by auditing the tool chains and kernels you are using, to understand any changes they have made downstream from the canonical kernel and gcc releases. In the case of RedHat, I believe they require you to build the kernel with their tool chain. They will not support any modifications to the build process or the kernel. So, in a situation such as you describe, you are likely on your own. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040
On Sat, May 4, 2013 at 1:54 AM, Karen Shaeffer <shaeffer at neuralscape.com> wrote:> On Fri, May 03, 2013 at 11:11:30PM +0800, Jovi Zhang wrote: >> Hi, >> >> Is it possible to link native codes generated by different compiler? >> >> the usecase could be: >> Linux kernel compiled by gcc want to load kernel module compiled by Clang >> (I know there have some problem to compile kernel by Clang currently, >> but ignore those problem in here) >> >> I just concern about the call conversion problem, and compatibility >> between gcc and clang. > > Hi Jovi, > It can be complicated. Many distributions patch gcc, the kernel, and the > entire tool chain. A good example is RedHat, which applies many many patches > to the kernel and the tool chain, including gcc. I believe embedded releases > are similar. The canonical kernel releases are only tested on specific canonical > versions of gcc. While I am certain you can realize this goal, you might run into > some subtle problems. I would start by auditing the tool chains and kernels you are > using, to understand any changes they have made downstream from the canonical kernel > and gcc releases. In the case of RedHat, I believe they require you to build the > kernel with their tool chain. They will not support any modifications to the build > process or the kernel. So, in a situation such as you describe, you are likely on > your own. >Thanks Karen, your info is helpful for me. I will check the tool chain firstly.
Maybe Matching Threads
- [LLVMdev] link native code compiled by llvm and gcc?
- [LLVMdev] link native code compiled by llvm and gcc?
- [LLVMdev] A new mechanism to compiler kernel modules using llvm: Defer type evaluation in clang?
- [LLVMdev] GCC/LLVM frame pointer incompatibility on ARM
- this ir code segfaults llvm in trunk