如何查看gcc编译器编译时的include头文件搜索路径、各默认路径通常用于存放何种头文件、gcc编译器搜索头文件时不会去搜索默认路径中的子目录怎么办【头文件的目录嵌套】?

gcc头文件搜索路径详解:一条命令解决找不到头文件的烦恼 在C/C++开发中,头文件搜索路径是影响编译成败的关键因素之一。编译器如何定位标准头文件,取决于内置的搜索顺序和用户配置。理解gcc的头文件查找机制,不仅能解决“stdio.h: No such file or directory”之类的报错,还能帮助开发者更好地配置构建系统、IDE和交叉编译环境。通过gcc -v -E等命令,可以直观查看系统头文件路径及其优先级,从而快速定位环境变量、搜索顺序导致的问题。本文结合实际工程场景,讲解如何利用这些命令高效排查编译障碍。 阅读详情

01-如何查看gcc编译器编译时的头文件搜索路径

扩展阅读:gcc的链接器的相关知识要点,这里面我写了如何查看链接器的默认搜索目录。
这里说下如何查看gcc编译器编译时的头文件搜索路径,用下面的命令:

echo | arm-buildroot-linux-gnueabihf-gcc -E -v -

输出结果中有下面的内容:
在这里插入图片描述

#include "..." search starts here:
#include <...> search starts here:
 /home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/include
 /home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/include-fixed
 /home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/../../../../arm-buildroot-linux-gnueabihf/include
 /home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/sysroot/usr/include
End of search list.

这里边就列举了#include <...> 的搜索路径。
值得注意的是:在上面的路径中,… 表示父目录。工具链在运行时会解析这些相对路径并转换为实际的绝对路径。
例如:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin/../lib

在下面的目录结构下:
在这里插入图片描述
会转化为:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/lib

因为 bin/../ 实际上指向的是 bin 目录的父目录。
基于这个原理,我们把上面的四个目录路径转化为绝对路径为:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/include

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/include-fixed

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/include

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/sysroot/usr/include

02-四个默认搜索头文件路径通常放什么类型的头文件,自己编译的第三方库的头文件放于哪里?

问:我对上面的四个相对路径进行了手工解析,结果如下:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/include

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/lib/gcc/arm-buildroot-linux-gnueabihf/7.5.0/include-fixed

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/include

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/sysroot/usr/include

如果我想把tslib库的头文件放到这几个目录中,你说放到哪个目录下比较合适?

以下是对这几个目录的分析和建议:

目录分析

  1. .../7.5.0/include

    • 用途:这是 GCC 特定的标准头文件目录,通常包含 GCC 自身需要的内部头文件或特定版本相关的内容。
    • 建议:不建议放置第三方库头文件。这是 GCC 的私有目录,手动添加可能导致编译器行为异常。
  2. .../7.5.0/include-fixed

    • 用途:包含经过修正的头文件,可能用于替代标准库中的一些问题文件。
    • 建议:不建议使用。这个目录的内容通常由工具链维护,放置 tslib 头文件可能造成冲突或意外问题。
  3. .../arm-buildroot-linux-gnueabihf/include

    • 用途:通常是工具链的通用标准头文件目录,包括标准库头文件和常用库头文件。
    • 建议:可以考虑放置,但如果 tslib 是面向应用程序的库,放这里可能会增加工具链维护的复杂性。
  4. .../sysroot/usr/include

    • 用途:这是目标系统的头文件目录,通常包含与目标系统相关的库头文件(如 glibc 或其他系统级库)。
    • 建议:推荐放置这里。这是最常用的目录,符合目标文件系统的标准组织结构。应用程序或系统工具在编译时可以直接找到这些头文件。

推荐目录

将 tslib 库的头文件tslib.h放在上面四个目录中的最后一个,即:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/sysroot/usr/include/

03-gcc编译器搜索头文件时不会去搜索默认路径中的子目录怎么办【默认路径中嵌套子目录怎么办?】

如果你的库的头文件只是单一的一个头文件,那么可以在上面提到的几个目录中选一个来存放,这样编译器是可以搜索到的。
但是如果你的库的头文件不只一个头文件,而是一个目录,那是不能直接放目录的,因为默认情况下,GCC 编译器不会递归搜索 include 目录中的子目录。那这种情况下怎么办呢?请往后看。

比如tslib库的头文件就一个,那我可以直接放于下面这个目录中:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/sysroot/usr/include/

在这里插入图片描述
这是可以的。

但是像freetype库它的头文件的目录结构就比较复杂,它的结构如下:
在这里插入图片描述
在这里插入图片描述在这里插入图片描述

E:\freetype2
│  ft2build.h
│
└─freetype
    │  freetype.h
    │  ftadvanc.h
    │  ftbbox.h
    │  ftbdf.h
    │  ftbitmap.h
    │  ftbzip2.h
    │  ftcache.h
    │  ftchapters.h
    │  ftcid.h
    │  ......
    │
    └─config
            ftconfig.h
            ftheader.h
            ftmodule.h
            ftoption.h
            ftstdlib.h

这种情况下为了让编译器能进入默认搜索路径的子目录中去搜索,你需要在默认搜索路径中放一个头文件,让这个头文件去告诉编译器进入子目录中去搜索,比如freetype库中的头文件ft2build.h
在这里插入图片描述
它里面的内容如下:

#ifndef FT2BUILD_H_
#define FT2BUILD_H_

#include <freetype/config/ftheader.h>

#endif /* FT2BUILD_H_ */

我们看到,它里面其实就一条语句:

#include <freetype/config/ftheader.h>

这条语句就会让编译器以上面的四个默认搜索路径为根路径,然后加上相对路径freetype/config/ftheader.h去查找相应的头文件。
我实测过,把文件ft2build.h放在一个默认搜索路径中,把目录freetype放于另一个搜索路径中,相关的freetype的工程源码也能顺利编译哦。

而在文件freetype/config/ftheader.h中其实又是各需要的头文件的相对路径,摘录如下:

#define FT_TYPES_H  <freetype/fttypes.h>

#define FT_LIST_H  <freetype/ftlist.h>

#define FT_OUTLINE_H  <freetype/ftoutln.h>

......

所以总结下,尽管编译器不会进入默认路径的子目录中去搜索头文件,但你可以在其默认路径存放的头文件中存放中为需要的头文件指明相对路径,这样编译器是可以获取到相关的头文件的。

对于freetype库而言,我的操作是把其make install获取到的头文件目录freetype和头文件ft2build.h放于下面这个目录中:

/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/arm-buildroot-linux-gnueabihf/sysroot/usr/include/

在这里插入图片描述

在这里插入图片描述

gcc, vc 编译输出头文件包含顺序 g++ -H 打印头文件包含顺序和有效性 作者: dzqabc 博客: https://www.cnblogs.com/dongzhiquan/archive/2013/04/11/3013486.html 发布: 2013-04-11 00:24 g++ -H 选项 有时为定位一些如头文件循环包含致编译不过问题,我们要知道头文件包含顺序。 g++ -H 除了进行正常编译,还会打印每个头文件的名称。每个文件通过缩进表示它在包括堆栈中的深度。无效的预编译头文件也会打印出来;无效的预编译头文件打印…x, 阅读详情

相关推荐

gcc使用手册

库是已经编译好并能被链接入程序的对象文件的“集合” 库通常被存储在扩展名为.a的特殊归档文件中,被称为静态库。它们使用一个单独的工具,GNU的归档器ar,从对象文件生成 编译器选项-lNAME 试图链接“标准库目录下”的文件名为libNAME.a中的对象文件,该选项很少使用 注意理解标准库目录*** 默认的搜索路径也可以包括其他依赖于系统或指定位置的目录,和gcc在安装时的目录。在64位平台上,l...

凌动处理器的博客 614

【博客132】Linux动态库搜索路径

内容: 记录linux搜索动态库时的可能路径 一.搜索规则 Linux动态库的默认搜索路径是/lib和/usr/lib。动态库被创建后,一般都复制到这两个目录中,这样才能 被找到。当程序执行时需要某动态库,并且该动态库还未加载到内存中,则系统会自动到这两个默认搜索路径 中去查找相应的动态库文件,然后加载该文件到内存中,这样程序就可以使用该动态库中的函数,以及该动态 库的其它定义内容。 注意:并不...

qq_43684922的博客 879

从Makefile错误到头文件路径:C/C++构建系统核心问题解析与交叉编译实战

在C/C++项目开发中,构建系统是连接源代码与可执行程序的桥梁,其核心在于管理编译依赖与资源定位。Makefile作为经典的构建描述文件,通过定义目标、依赖和规则来控制构建流程,其语法错误(如制表符误用)和逻辑错误(如循环依赖)是导致构建失败的常见原因。编译器在预处理阶段需要根据头文件搜索路径机制定位#include指令引用的文件,路径配置错误会引发“No such file or directory”错误。这些基础概念在嵌入式开发和物联网项目中尤为重要,因为交叉编译要求为不同处理器架构(如从x86到ARM

weixin_30896511的博客 494

gcc头文件默认搜索路径

gcc头文件默认搜索路径

bdn_nbd的博客 990

Android AudioFlinger(一)——初识AndroidAudio Flinger

AudioFlinger 是 Android 系统中的音频中间层(audio HAL, Audio Hardware Abstraction Layer)的一部分,负责管理音频的混音、播放和音量控制等功能。它充当 Android 应用程序和音频硬件之间的桥梁。

hirezy 1655

通过薄膜太阳能电池中的热激电流量化陷阱状态

发光(led)和光伏(PV)器件的性能取决于光活性半导体材料的质量。由于材料杂质或在制造过程中在半导体材料中无意地引入缺陷,导致偏离最佳性能。这些缺陷被称为阱态,或简称“阱”,它是半导体带隙内的高能态。一般来说,陷阱的发生可能是由于材料杂质(在散装)或在不同材料层之间的界面。在有机半导体中,由于天然物质的无序性,阱态经常出现。在无机和杂化半导体(例如:杂化钙钛矿、硅……)中,晶界的存在是圈闭态的已知来源。由于陷阱产生的原因多种多样,它们对装置的影响也是多种多样的。由于载流子的多次捕获和释放事件,特别是浅阱的

FluximAG的博客 2841

GCC编译的时候头文件搜索规则

GCC编译的时候头文件搜索规则

weixin_44698673的博客 3999

从SPI到JTAG:玩转FT2232H的MPSSE多协议切换指南(附配置代码)

本文详细介绍了如何利用FT2232H芯片的MPSSE技术实现SPI与JTAG协议的无缝切换,提供配置代码和调试技巧。通过解析MPSSE引擎架构和硬件特性,帮助开发者灵活应对多种串行协议需求,提升嵌入式开发效率。特别适合FPGA调试和物联网设备开发场景。

sun99的博客 252

修改gcc/g++默认include路径

修改gcc/g++默认include路径 转自:http://www.network-theory.co.uk/docs/gccintro/gccintro_23.htmlhttp://ilewen.com/questions/692   C/C++程序在linux下被编译和连接时,GCC/G++会查找系统默认的include和link的路径,以及自己在编译命令中指定的路径。自己指定的路径就不说了...

weixin_34337265的博客 1598

适合初学者的ROS机器人教程(1): Ubuntu下ROS创建自己的包和使用github下载的包

ROS如何创建自己的包 1. 首先创建catkin工作空间(如果你以及有了请忽略) $ mkdir catkin_ws # 创建一个文件夹里面计划放我们的项目,ws是workspace的缩写 $ cd catkin_ws # 将当前工作文件夹切换到catkin_ws这个文件夹 ~/catkin_ws$ catkin_make # 执行catkin_make创建一ROS项目 此时你的catkin_...

@司南牧|知乎|博客|易懂教程|李韬 3235

TDDFT计算软件Octopus学习笔记(二):基态计算(Si)

本文以硅为例,来进行基态计算。

陈啸的博客 7296

如何查看和修改gcc、g++默认include路径

如何查找gcc、g++默认include路径?注意:"`"是Tab上面的那个符号。 #gcc `gcc -print-prog-name=cc1plus` -v #g++ `g++ -print-prog-name=cc1plus` -v 我们都知道在编译的预处理阶段, 编译器会展开所有的#include<...>和#include"..."文件,那么编译器是按照什么顺序...

慢慢冲鸭子的博客 2万+

工业质检实战:如何用MVTec AD数据集训练你的第一个无监督异常检测模型

本文提供了一份基于MVTec AD数据集的工业质检实战指南,详细介绍了如何从零开始训练一个无监督异常检测模型。内容涵盖数据预处理、模型架构选型(如CAE、GAN与特征字典方法)、特征提取、损失函数设计以及关键的阈值确定与后处理流程,旨在帮助工程师快速掌握将AI技术落地于实际产线质检的核心步骤与调参经验。

weixin_29182481的博客 452

Keil MDK 5.37头文件找不到报错:AC6编译器Include Paths配置实战

在嵌入式开发中,头文件搜索路径是编译器完成源码编译前的关键环节。当使用双引号包含本地头文件时,编译器会依据当前源文件目录、命令行-I参数以及系统内置目录的固定顺序进行查找。在Keil MDK环境中,若工程文件分散存放,必须手动配置Include Paths,否则极易出现“No such file or directory”的编译失败。尤其升级到MDK 5.37后,默认的AC6编译器(armclang)改变了以往AC5的宽松查找行为,要求路径配置必须显式且完备,这也成为STM32开发者迁移工程时的高频痛点。本

weixin_34293059的博客 374

Python爬虫实战:高效爬取中国专利数据库的完整指南

在当今信息爆炸的时代,专利数据作为技术创新的重要指标,对企业研发、市场分析和学术研究都具有极高价值。中国作为全球专利申请量最大的国家,其专利数据库包含了海量的技术创新信息。本文将详细介绍如何使用Python最新技术构建一个高效、稳定的中国专利数据库爬虫系统。中国专利数据库主要由国家知识产权局(CNIPA)维护,包含发明专利、实用新型专利和外观设计专利三大类。截至2023年,中国专利数据库已收录超过400万件发明专利和300万件实用新型专利。

2201_76125261的博客 1564

Realtek千兆PHY RTL8211FS相关寄存器操作详解

通过合理配置和控制RTL8211FS寄存器,您可以实现对以太网的各种功能和参数的控制和配置。请注意,具体的寄存器操作和配置值可能因具体需求而有所不同,您应参考RTL8211FS芯片的数据手册以获取准确的寄存器说明和操作规范。我们将提供相应的源代码示例,以帮助您理解和实施这些操作。通过操作这些寄存器,我们可以配置和控制RTL8211FS芯片的各种功能和参数。需要注意的是,具体的寄存器操作和配置值会根据您的具体需求而有所不同。您需要参考RTL8211FS芯片的数据手册以获取详细的寄存器说明和操作规范。

RlDart的博客 2652

C语言include头文件包含与预处理调试实战指南

在C语言工程开发中,include指令与预处理机制是最容易被忽视却极易引发编译错误的环节。头文件包含顺序、搜索路径、宏定义展开以及条件编译,共同决定了编译器“眼中”的源码形态。理解预处理原理,掌握gcc -E、-H等调试工具,能快速定位重复包含、循环依赖所导致的编译错误与链接错误。从基础概念到实践排查,这些技能对于多文件工程的头文件治理与宏调试尤为重要,能显著提升底层调试效率。

weixin_32075843的博客 266

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

预处理过程:头文件

本文学习编译器在预处理过程中对头文件的处理。Hightec编译器版本是tricore v4.9.1.0。博主在<基于模型的设计>板块就经常提到头文件,本文会从编译器的角度对头文件进行学习。 文章目录1 Include语法2 编译器对Include的处理3 头文件的搜索路径4 只加载一次头文件4.1 问题4.2 通过条件编译只加载一次头文件5 总结 1 Include语法 头文件一般包含C语言的声明和宏定义。在C语言源文件中,通常在最上面用#include指令调用,俗称为包含某个头文件。 头文件一

u013288925的博客 3840

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

别只盯着apt install:深入理解Linux头文件路径与编译器的-I选项实战

本文深入探讨Linux头文件路径与编译器-I选项的实战应用,解析`drm.h`等头文件缺失错误的本质原因。通过对比内核头文件与用户态头文件的区别,详解-I选项的进阶用法及构建系统中的路径管理技巧,帮助开发者高效解决编译问题,提升开发效率。

weixin_30509393的博客 461

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

C/C++中#include尖括号与双引号的区别:搜索路径、编译器行为与工程实践

在C/C++开发中,#include预处理指令是构建源码依赖关系的核心机制,而尖括号<>与双引号""的选用直接决定了头文件的搜索路径与编译成败。理解预处理器如何展开头文件、编译器如何按优先级查找目录,是解决“No such file or directory”和IDE中“检测到#include错误”等高频问题的关键。不同编译器(GCC、Clang、MSVC)在搜索顺序上存在细微差异,工程中需根据头文件来源——标准库、第三方库还是项目内部——做出合理选择,并通过构建系统统一管理include路径。本文系统梳理

weixin_32244597的博客 93

c语言中#include 路径查找问题

在程序设计中,文件包含是很有用的。一个大的程序可以分为多个模块,由多个程序员分别编程。有        些公    用的符号常量或宏定义等可单独组成一个文件,在其它文件的开头用包含命令包含该文件即可使        用。这样,可避免在每个文件开头都去书写那些公用量,从而节省时间,并减少出错。 对文件包含命令还要说明以下几点: 1. 包含命令中的文件名可以用双引号括起来,也可以用尖括号括起来

xiaoshengqdlg的专栏 3万+

gcc整理

1.-Wall 告警选项,可以输出告警信息 例如printf("%f\n", 4) 会输出double format, different 可以捕捉到c编程中最常发生的错误 可以对部分内容告警,而不使用all 使用-Wcomment 对嵌套注释告警 -Wformat 对格式化误用的告警 -Wunused 没有使用到的变量告警 等等其他 2.gcc -Wall -c main.c 编译m...

qq_22226911的博客 155

CMake target_include_directories:精准管理C++头文件依赖的现代实践

在C/C++项目构建中,头文件依赖管理是影响代码模块化和可维护性的基础问题。传统全局包含路径的方式容易导致依赖污染和编译冲突,而现代构建工具通过目标级别的依赖声明来解决这一痛点。CMake作为广泛使用的跨平台构建系统,其target_include_directories命令实现了依赖关系的精确控制,通过PUBLIC、PRIVATE和INTERFACE三种作用域,模拟了面向对象编程中的访问权限概念,让库的接口与实现分离。这一机制不仅提升了代码的封装性,还支持依赖的自动传递,特别是在大型项目和模块化架构中价值

weixin_34075268的博客 416

Keil MDK头文件路径配置全攻略:3步解决STM32编译报错

在嵌入式开发中,STM32工程编译时常遇到“No such file or directory”的报错,这通常与C语言编译器的头文件搜索机制有关。编译器不会自动遍历子目录,而是依赖开发者明确指定的Include Paths。理解头文件搜索顺序与依赖关系,是解决此类问题的核心。通过正确配置Keil MDK的路径,不仅能消除报错,还能提升工程的可移植性,尤其在多人协作或跨平台开发时至关重要。本文从编译器原理出发,结合STM32 HAL库与CMSIS常见目录结构,提供一套可直接落地的排查与配置方法,帮助开发者快速

weixin_33908217的博客 329

C/C++头文件命名冲突:从标准库覆盖到项目结构优化的安全编程实践

在C/C++编程中,头文件是模块化开发的核心组件,其核心作用是声明函数、宏和类型,供多个源文件共享。编译器通过预定义的搜索路径规则(如`#include`指令的尖括号与双引号区别)来定位头文件。若命名不当,极易引发命名空间污染,导致编译错误或链接失败,严重影响项目的可维护性和团队协作效率。其技术价值在于通过清晰的命名和路径管理,确保编译单元的一致性,从而构建健壮的软件架构。这一实践在嵌入式开发、系统编程及大型项目协作中尤为重要。例如,在STM32开发中,若自定义头文件与标准库的`math.h`重名,会因路径

weixin_30435261的博客 434

STM32CubeIDE中链接脚本如何include头文件?三步实现单一数据源

嵌入式开发中,内存布局与地址定义常分散在C头文件和链接脚本中,手动同步极易引发Bootloader跳转错误或OTA升级失败。GNU ld内置预处理器使其支持宏替换与条件编译,但直接包含工程主头文件会因混入typedef、函数声明等C语法导致数百行报错。通过创建仅含# define等预处理指令的纯净配置头文件,配合相对路径引入,即可在链接脚本中复用同一份地址宏,实现C代码与链接脚本的单一数据源管理。该方法在STM32CubeIDE中稳定可靠,适合分区规划、多硬件版本适配等场景,显著降低由地址不一致引发的Har

weixin_34268579的博客 321
上一篇: 在C语言中,字符指针“char *name”和字符数组“char name[]“各自适用哪些场景?
下一篇: 嵌入式开发之使用 FileZilla 在 Windows 和 Ubuntu 之间传文件
昊虹AI笔记
博客等级 码龄11年 4439粉丝 981原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

昊虹AI笔记

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值