跳转至内容

Open source | 开源

开源软件 | 开源社区 | 开源理念 | 开源与商业 | 开源可持续发展 等相关话的交流讨论
注: 这里的"开源"是泛化的共建共享概念, 范围包含 OSI的范围、自由软件、CC等相关内容

49 主题 208 帖子

子版块


  • 一个开源的技术学习、软件工具便捷下载、教程教学类项目构建和管理工具 - Github

    37 主题
    145 帖子
    SPeakS
    背景

    前段时间社区中xlings项目上有人提了一个关于centos7上 安装gcc15的但是不能使用的问题, 我一看原来是由于glibc的版本太老了导致的 (制作gcc15包的时候我也没考虑太多glibc版本依赖问题)

    于是我就折腾了几天给xlings工具增加了一个从源码构建gcc工具链的helper工具 musl-cross-make, 同时也提供了一个预构建的gcc15包, 让我们在centos7上可以用下面简单的方法就能安装gcc15或自己从源码构建gcc15. 最终效果如下:

    一键安装gcc15 xlings install gcc@15 自己在本地 一键从源码构建gcc15 xlings install musl-cross-make #安装构建helper工具 # 命令格式: musl-cross-make version [--output yourOutputDir] [--target yourTargetArch] musl-cross-make 15 --output mygcc-15 原issues: https://github.com/d2learn/xlings/issues/107 xlings开源工具: https://xlings.d2learn.org

    下面是具体的问题解决过程, 以及 centos上 一键创建支持cpp23的cmake模板工程项目的使用示例&演示...

    一、问题和解决的过程 Q1: GLIBC的版本依赖问题 https://github.com/d2learn/xlings/issues/107#issue-3300789666 root/.xlings_software_install/xlings-main/bin/xmake: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /root/.xlings_software_install/xlings-main/bin/xmake) /root/.xlings_software_install/xlings-main/bin/xmake: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /root/.xlings_software_install/xlings-main/bin/xmake) /root/.xlings_software_install/xlings-main/bin/xmake: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by /root/.xlings_software_install/xlings-main/bin/xmake) tools/install.unix.sh:行65: xlings: 未找到命令 A1: 使用musl静态构建解决libc的依赖问题 - 已解决

    4bd6a426-c93c-4733-9075-fad0bd686261-image.png

    Q2: xlings install gcc@15.1.0安装后工具链的使用问题 https://github.com/d2learn/xlings/issues/107#issuecomment-3167203522 A2: 更新了gcc包(包括15.1.0)对centos的支持, 添加了可从源码构建包的选择及工具 gcc: 预先构建的二进制gcc工具链包 安装命令示例: xlings install gcc@15 fromsource:musl-gcc: 从源码构建基于musl的gcc工具链的xpkg包 安装命令示例: xlings install fromesource:musl-gcc@version musl-cross-make: 可自定义的工具链构建helper工具 安装命令示例: xlings install musl-cross-make 使用命令示例: musl-cross-make version --output yourInstallDir, musl-cross-make 9.4 --output mygcc-9 构建后会安装到当前目录的mygcc-9下

    原来的gcc

    9dd8c255-77dc-47ff-b5b6-6c6345fd1ae4-image.png

    安装gcc15

    c1b573d2-6a4d-4150-ba6d-c4b57015f415-image.png

    2eae2930-e8ba-440c-9742-dcaf5ee84ab3-image.png

    二、xlings在centos上的一些使用示例 (gcc工具链 + cpp23 import std模块)

    会自动安装依赖(gcc15 / cmake4 ...) , 并配置好环境

    一键创建模板项目 + 自动安装依赖和配置环境

    2c595d41-d0ed-424f-ada7-93ef240a09a7-image.png

    构建&运行演示

    aee61b54-60b2-4a53-8060-9d14f1462269-image.png

    三、其他 相关的issus: https://github.com/d2learn/xlings/issues/107 xlings工具文档: https://xlings.d2learn.org/documents/quick-start/one-click-install.html xlings工具仓库: https://github.com/d2learn/xlings 包索引仓库: https://github.com/d2learn/xim-pkgindex xlings社区论坛交流版块: https://forum.d2learn.org/category/9/xlings
  • 《计划-投射》快速绘制节点图的桌面工具,可以用于项目进程拓扑图绘制、快速头脑风暴草稿 - Github

    2 主题
    11 帖子
    sunrisepeakS

    @1049010335 基本元素是指的是做成组件式吗 直接创建表格?

  • 如果你的开源软件被人分发,应该如何应对

    已移动
    7
    0 赞同
    7 帖子
    104 浏览
    sunrisepeakS

    @yigekuyou 在 如果你的开源软件被人分发,应该如何应对 中说:

    错误日志应该后提交给我还是提交给开发者

    如果是你修改的版本, 一般先提交给你, 如果你发现非修改部分造成的, 你再提交到上游

  • GPL开源协议的传染性问题

    11
    0 赞同
    11 帖子
    230 浏览
    yigekuyouY

    就算GPL也保留了闭源的能力,传染性让GPL协议可能会和其他开源协议产生冲突,以链接的形成的lgpl反而安全些

  • 0 赞同
    3 帖子
    204 浏览
    yigekuyouY

    重写从开源协议上应该是衍生物,也不需要纯净室开发

  • 开源的好处与坏处分析总结

    9
    1 赞同
    9 帖子
    235 浏览
    sunrisepeakS

    @Littlefean 可以搞赞助 vue 好像就这么发展的。但是mit使用好像并不需要手动授权好像

  • 开源协议总结

    4
    1 赞同
    4 帖子
    231 浏览
    LittlefeanL

    @sunrisepeak 在 开源协议总结 中说:

    CC和OSI感觉最主要的冲突点应该是 "是否能商用自由"

    确实,NC直接禁止商用了。CC系列感觉范围主要是一些创意作品而非软件了。感觉有人往github上发自己创作的一些“开源文章”可能有用吧。

  • MIT这个非常宽松的开源协议究竟保留了什么?

    5
    0 赞同
    5 帖子
    178 浏览
    sunrisepeakS

    @Littlefean 在 MIT这个非常宽松的开源协议究竟保留了什么? 中说:

    如果把游戏引擎的runtime打包到游戏里的时候一般就要包含了这部分的MIT协议。

    但这个回答是被动的,它是否需要开发者主动在“关于界面”或“开发者界面”里提出使用了这个引擎作为技术支持?

    一般来说是不强制要求在界面特别显示, 但是一般建议是在关于中提到。 但似乎这就是属于 "宽松" 区域, 但如果是一个要发行的商业软件, 一般默认尽可能的在关于进行标识比较好

  • 一些有趣幽默的开源协议收集与整理

    7
    0 赞同
    7 帖子
    178 浏览
    sunrisepeakS

    @Littlefean 开源协议 很多时候是为了传播和共享 会偏向 "宽松" , 并再使用上一般默认大家会尽可能的遵守 (似乎某种程度一些协议可能还有故意不想受很多规则的限制甚至包括法律? 但符合要符合现实世界规则一般还是要很多考虑的, 可能也是一个发展的过程...)

  • 开源协议的更换问题

    5
    0 赞同
    5 帖子
    130 浏览
    LittlefeanL

    确实,忘了版本号的问题了,依赖都是有固定版本号的,同一版本号里开源协议不能变但版本号变了开源协议就可以变了。

  • 此主题已被删除!

    1
    0 赞同
    1 帖子
    10 浏览
    尚无回复