blocks|key|624214|text|如果您使用GCC或Clang，-include+filename选项可能会有所帮助。它包括在其他任何东西之前的命名文件。见GCC预处理选项。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|624215|entityMap|0|LINK|mutability|MUTABLE|url|https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Preprocessor-Options.html#Preprocessor-Options^0|F|H|1P|8|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

If you're using GCC or Clang, the <code>-include filename</code> option might help.
It includes the named file before anything else.
See <a href="https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Preprocessor-Options.html#Preprocessor-Options" rel="nofollow noreferrer">GCC Preprocessor Options</a>.

blocks|key|133182|text|我正在跟进我的问题的答案，以防其他人发现这篇文章，通过搜索如何控制包含顺序，同时构建一个CFFI共享库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|133183|CFFI+.set_source方法有一个“extra_compile_args”参数，允许设置GCC选项，如Jonathan建议的-include选项。这应该解决了问题(所以我把他的答案标为解决方案)，但没有解决。这导致了我在上面的评论中提到的另一个问题，我在这里发布了另一个问题(GCC抱怨说“没有这样的文件或目录”，但是文件存在，它的名字是正确的--真的--那么有什么问题呢？)。|offset|length|133184|没有办法解决这个问题，所以我想出了一个办法来解决这个问题。我用源代码在同一个目录中创建了一个小的Python.h头，并在其中放置了两个include语句--一个必须放在所有其他头之前的头的包含，以及一个真正的Python.h头的包含。实际的Python头是通过其绝对路径引用的，这意味着在使用另一个Python版本时存在维护问题。|133185|还有一个我提到的问题，因为我在这里询问的问题与我的项目直接相关(而且可能是唯一的)，即为linux核心实用程序之一构建一个带有Python绑定的共享库。如果你找到这篇文章，你可能会尝试做一些类似的事情。静态库libcoreutils.a是必需的，但是它是在没有GCC选项-fPIC的情况下构建的，构建共享库需要这个选项。coretuils中的注释表明，省略此选项是有意的，以避免至少64位系统上的潜在问题。换句话说，您必须为这个库构建自己的PIC替换程序。|133186|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/73159589/gcc-complains-no-such-file-or-directory-but-the-file-exists-and-its-name-is-ty^0|0|3Y|1D|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I am following up with an answer to my question just in case someone else discovers this post through a search on how to control the include order while building a CFFI shared library.
The CFFI .set_source method has an 'extra_compile_args' parameter that allows setting GCC options like the -include option suggested by Jonathan Leffler. That should have solved the problem (so I marked his answer as the solution) but it didn't. It lead to another problem that I mentioned in my comment above and that I posted in another question here (<a href="https://stackoverflow.com/questions/73159589/gcc-complains-no-such-file-or-directory-but-the-file-exists-and-its-name-is-ty">GCC complains &#39;No such file or directory&quot; but the file exists and its name is typed correctly -- truly -- so what&#39;s the problem?</a>).
No solution could be found to solve that problem so I came up with a way to get around it. I created a small Python.h header in the same directory with my source code and put two include statements in it -- an include of the header that had to come before all other headers and an include of the real Python.h header. The actual Python header is referenced through its absolute path, which means there is a maintenance issue when another version of Python is used.
There is one other issue I encountered that I mention because the problem I asked about here is directly related to (and may be somewhat unique to) my project, which is to build a shared library with Python bindings for one of the linux core utilities. If you find this post, you may be trying to do something similar. The static library libcoreutils.a is needed but it is built without the GCC option -fPIC and that option is required to build a shared library. Comments in the coretuils makefile indicate the omission of this option is intentional to avoid potential problems on at least 64-bit systems. In other words, you will have to build your own PIC replacement for this library.

I am trying to build a shared library with CFFI for one of the Linux core utilities that I can call from Python. I have done this before for other C and C++ programs but this is my first attempt for one of the core utilities.
I finished modifying the utility's C code to provide a callable routine and I successfully tested it as a command-line program. The problem occurs when I attempt to compile it using CFFI.
When CFFI builds the C code to compile, it inserts a lengthy prefix of several hundred lines including an include of &lt;Python.h&gt; before it embeds the code of the core utility. This is normal but the core utilities include a header &lt;config.h&gt; that must precede other headers. The specific error I get is &quot;Please include config.h first.&quot; generated by the header &lt;unistd.h&gt; which was included from the Python.h header.
Does CFFI provide a way to modify the prefix that it generates so that I can stick &lt;config.h&gt; in it before the Python.h include? I suppose I could discover a way to modify one of more headers to get around this problem but I'd like to avoid modifications like that. What is the best way to get around this problem?

Need to control order of include files building a CCFI shared library

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在尝试为我可以从Python调用的Linux核心实用程序之一用CFFI构建一个共享库。我以前为其他C和C++程序做过这种工作，但这是我第一次尝试核心实用程序之一。我修改了该实用程序的C代码，以提供一个可调用的例程，并成功地将其作为命令行程序进行了测试。当我试图使用CFFI编译它时，会出现问题。当CFFI构建要编译的...

问需要控制构建CCFI共享库的包含文件的顺序
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问需要控制构建CCFI共享库的包含文件的顺序EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问需要控制构建CCFI共享库的包含文件的顺序
EN