gcc windows环境安装(目前13.2版本)
发布于: 2023-11-2
更新于: 2023-11-3
未收录
文章字数: 212
阅读时间: 1 分钟
阅读量:
文章目录
|
|
一、简介
- MinGW 和 MinGW-W64 区别和联系 MinGW和MinGW-W64都是用于Windows平台的轻量级GNU工具链，用于开发和编译C和C++程序。
MinGW（Minimalist GNU for Windows）是一个32位的GNU工具链，它提供了一套基于GNU的开发环境，包括GCC编译器和一些GNU库，可以用来编译Windows下的C和C++程序。但MinGW只支持32位程序的编译。
MinGW-W64是一个64位的GNU工具链，是MinGW的升级版，原本它是MinGW的分支，后来成为独立发展的项目，它支持同时编译32位和64位程序。它包括了一系列的GNU库和工具，例如GCC、Binutils、GDB等，还支持一些实用工具和库，如OpenMP、MPI等。
总的来说，MinGW-W64可以看作是MinGW的升级版，它支持更多的编译选项和更多的库，可以编译出更加高效和安全的程序。
另外，MinGW-W64原本是从MinGW项目fork出来的独立的项目。MinGW 早已停止更新，内置的GCC最高版本为4.8.1，而MinGW-W64目前仍在维护，它也是GCC官网所推荐的。
二、下载
MinGW-w64 源码地址：
官方没在任何地方提供二进制安装程序。 哪里找MinGW-w64二进制应用程序？ 下面提供几种方式：
1. 从 sourceforge.net 下载(不推荐)
不推荐在这里下载，因为这里提供的二进制安装程序是旧的，支持的GCC版本停留在了"MinGW-W64 GCC-8.1.0"
下载地址： https://sourceforge.net/projects/mingw-w64/files/
2. 从 github 下载(推荐)
选择x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z,下载地址：
3. 从镜像站点下载（推荐）
下载地址，选择要安装的版本：
4. 自己编译源码(不推荐)
三、安装与配置
这里介绍github.com的离线安装方式：
-
windows环境选择
x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z
下载地址： -
配置环境变量：
- 将下载的解压到指定目录，如我的windows环境： 把 C:/Sortware/gcc/gccV13.2/ 加入系统环境变量 Path 中去，方便我们命令行使用。
-
重新打开命令行执行gcc -v
|
|
四、总结
【从sourceforge.net下载】中提供的安装程序，支持的GCC 8.1.0，版本太老了，很多功能不支持，不推荐从这里下载安装； 【2. 从github下载】、【3. 从镜像网站下载】中提供的安装程序，支持的GCC版本都比较新，推荐从这里下载安装；
五、参考链接：
目录
相关文章
nginx 301跳转问题总结
1.nginx 301跳转问题背景 在使用hugo部署博客，部署方案nginx+docker,在浏览器地址使用url访问静态资源目录时，发现默认跳转到了http协议的地址。 调出浏览器发现客户端发送的http请求收到了一个301状态码的响应，并且响应头中的Location字段便是跳转到的http协议的地址。 2.原因分析 为啥服务端会返回301呢？首先需要弄清楚状态码的含义。HTTP协议中3xx开头的状态响应码都是表示重定向的响应。根据RFC的定义：
301 Moved Permanently
302 Found
303 See Other
307 Temporary Redirect
301是永久重定向。如果使用Nginx作为HTTP服务器，那么当用户输入一个不存在的地址之后，基本上会有两种情况：1.返回404状态码，2.返回301状态码和重定向地址。404 Not Found不做讨论，只说下301 Moved Permanently的处理过程。 首先需要明确的问题是，301重定向在什么情况下会被触发呢？
答案是：Nginx负责设置301 Moved Permanently状态码。但nginx.conf控制Nginx如何处理301 Moved Permanently状态码！ 换句话说，要不要进行页面重定向，和怎么重定向，完全是用户配置的结果！ Nginx主动设置301 Moved Permanently状态码只有一种情况，当用户在浏览器输入了一个url地址，末尾部分是一个文件目录且不以斜杠”/“结尾，比如 “www.test.com/index” 。 Nginx没有找到index这个文件，但发现了index是个目录。于是本次访问的返回状态码就会被设置成301 Moved Permanently。 浏览器与Nginx的通信过程如下所示：
一般情况下，我们会在nginx.conf中配置absolute_redirect ，server_name_in_redirect和port_in_redirect，以便到达个性化的重定向功能。其中absolute_redirect控制Location url的生成方式。
absolute_redirect设置成on，则生成绝对路径作为Location url。 absolute_redirect设置成off，则生成相对路径作为Location url。 只有absolute_redirect设置为on时，另外两个配置才会生效。
3. 解决方法 设置absolute_redirect为off，构造相对路径作为Location url，示例如下：
2023-7-25
goland IDE追新
追新2023，goland激活码快速激活至2099年！ 当前教程支持的版本：2020.2 ~ GoLand 2023.2 232.8453.111
前言：
goland 软件开发公司 jetbrains 在 2022 年 4 月发布了 goland 2022年第一个大版本2022.1，同时也带来了最严厉的反破解机制，之前所有的破解方案全部失效！在这样的背景下，在奋战了几周左右之后还是成功破解了最新版本2022.1.2！之前的教程中，在破解过程中需要各位码友们自己去操作一些东西，改一下配置，造成了部分不仔细的码友 goland 重启后打不开（虽然后续联系到我修复并激活成功，但是这样确实浪费时间和精力）。同时由于各个版本的配置稍微有些变化，所以本次教程更新给大家带来真正硬核的破解方式：一键脚本激活！！！不需要各位码友有任何多余的操作，只需要双击 vbs 脚本执行，然后重启 goland 就可以完成激活！
注意：本脚本做了向下兼容到2020.1，如果您不想升级，直接执行脚本后重启软件就可以完成激活！
破解过程详解：
1、软件准备 （1）goland 软件安装包（官网下载安全又快速）：https://www.jetbrains.com/goland/download/#section=windows
（2）获取激活码，激活包下载。各位码友们只管关心下图中 golandActive.vbs 脚本文件即可！
网盘地址(2023/07/23更新)：https://pan.baidu.com/s/1hVWbs9z-Deu5RmQ0PO0hTQ?pwd=3fo7
提取码：3fo7
网盘下载后文件zip解压密码：abc1
2、破解过程 2.1软件安装 在官网下载软件后一直点击 Next 即可（已经安装的码友们不用理会），然后打开 goland，发现需要注册！这里我们先不管，先点击 Exit 退出，准备开始运行激活脚本。 2.2 获取激活码 请确保 goland 软件处于关闭状态！ 鼠标双击网盘下载的破解包里面的 golandActive.vbs 得到如下界面，点击确定按钮即可！
2023-7-21
kubernetes常用命令
1. 将service端口暴露到本地 比如将生产环境的redis暴露到本地6379端口
1 kubectl port-forward service/redis -n [namesplace] 6379:6379 2. 进入容器中 kubectl exec -it [pod] -n [namesplace] -- bash 3. 查看日志 查看最后1行的日志
kubectl logs -f --tail 1 [pod] -n [namesplace] 查看最后一分钟的所有日志
kubectl -n [namesplace] logs [pod] --since=1m 查看指定时间
kubectl -n -n [namesplace] logs -f [pod] --since-time="2022-10-24T02:54:03.467+01:00" 4. 查看配置： kubectl get pod product-6b5c98478b-rpgr6 --namespace=product-prod -o yaml
kubectl describe pods product-6b5c98478b-rpgr6 --namespace=product-prod 5.
2023-5-10
ubuntu22.04安装gitlab
1. gitlab安装前准备 系统版本：Ubuntu 22.04.1 LTS 1.1 更新系统环境 sudo apt update
sudo apt upgrade 1.2 安装和配置必须的依赖项 1 2 sudo apt-get install -y curl openssh-server ca-certificates tzdata perl sudo apt-get install curl 2.下载和安装gitlab 2.1 下载指定的版本 1 curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash 2.2 开始安装 注意：localhost为访问gitlab的地址，85为访问gitlab的端口号
1 sudo EXTERNAL_URL="http://localhost:85" apt-get install gitlab-ce=15.9.3-ce.0 除非您在安装过程中指定了自定义密码，否则将随机生成一个密码并存储在 /etc/gitlab/initial_root_password文件中(出于安全原因，24 小时后，此文件会被第一次 gitlab-ctl reconfigure 自动删除， 因此若使用随机密码登录，建议安装成功初始登录成功之后，立即修改初始密码）。使用此密码和用户名 root 登录。
2023-4-28
使用aws-cloudfront做CDN转发
CND转发到v2ray服务 环境:
域名一个 aws cloudfront服务 数据转发流程 A.example.com->cloudfront->B.example.com->ip.ec2.port 注意事项 踩过的坑： v2ray-plugin报错 http: TLS handshake error from 64.252.173.97:23912: read tcp 172.21.0.3:443->64.252.173.97:23912: read: connection reset by peer 原因为2层(EC2,cloudfront)TLS证书不一致; 第一个想法就是将两个证书整成一致，然后cloudfront就上传"Let’s Encrypt自签的证书，发现使用自上传的证书cloudfront根本不转发数据了;得出一个结论:cloudfront必须使用它请求生成的tls证书； 解决方案：A.example.com->cloudfront->ip.ec2.port转发流程修改为A.example.com->cloudfront->B.example.com->ip.ec2.port v2ray-plugin报错not found in 'Sec-Websocket-Version' header 1 cloudfront ws一直是v2ray.com/core/transport/internet/websocket: failed to convert to WebSocket connection > websocket: unsupported version: 13 not found in 'Sec-Websocket-Version' header 原因是cloudfront没有配置转发HTTP请求头,CloudFront 预设并不会转发所有的 HTTP request headers， 有些 request headers 在经过 CloudFront 之后就被丟掉了导致 v2ray 无法识别到必要的数据。 需要更改 origin request policies 為 Managed-AllViewer，這樣它才會轉發所有的 headers。 - 解决方案：cloudfront设置源请求策略为```Managed-AllViewer```
cloudfront转发数据到源失败，解决方法是需要更改行为策略->缓存策略名称(Managed-CachingDisabled)->源请求策略名称(Managed-AllViewerExceptHostHeader) 源服务器没有接收到数据,错误的提示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 root@localhost ~ # curl -v https://proxy.
2023-3-20
赞赏
微信支付
