Go不支持动态库影响

530 views
Skip to first unread message

Marvin Guo

unread,
Nov 28, 2011, 10:17:39 PM11/28/11
to golang...@googlegroups.com
本来我是回复在另一个主题,现在另起一个主题,想和大家讨论一下Go不支持动态库影响。
这里不讨论不支持动态库原因,只是想知道大家对这个问题的认识。

我的理解
现代的操作系统内置动态库支持,系统核心是动态库导出,如果一门语言不支持动态库,也就不能充分和操作系统结合。
我认为这会阻碍Go成为系统级语言,这和Go的定位有冲突。

有人有想法吗?加我,单聊,邮件都可以。

mikespook

unread,
Nov 28, 2011, 11:32:13 PM11/28/11
to golang...@googlegroups.com
go 对动态库的支持是通过 cgo。现在的“不支持”,我觉得只是一个狭义的说法。

另外,go显然并不准备直接取代 c。我觉得Go作为网络系统级语言这个定位很精准。

贤 曹

unread,
Nov 28, 2011, 11:46:07 PM11/28/11
to Golang-China
不支持动态库的确非常不爽啊一个hello word 就2M郁闷的很

Howard Fan

unread,
Nov 28, 2011, 11:47:44 PM11/28/11
to golang...@googlegroups.com
我觉得只要 Rob 和 Ken 对Go
还有控制,就不会直接支持动态库。他们一直都认为动态库会造成程序的不稳定和运行的不确定性,因为,你测试的库和用户运行的可以不同,程序依赖的库可能不存在或版本不同造成无法运行,甚至在某些系统(不点名)可以骑劫DLL等。这些静态链接都可避免。

至少现在还没有必须支持动态库的必要。以后嘛,希望也不需要。

2011/11/29 mikespook <mike...@gmail.com>:

chai

unread,
Nov 28, 2011, 11:53:12 PM11/28/11
to golang...@googlegroups.com
我也不喜欢动态库.

感觉现在最急需的还是go的功能. 
如果功能都还没稳定就纠结动态加载实在没必要.
--
chaishushan

Howard Fan

unread,
Nov 28, 2011, 11:54:53 PM11/28/11
to golang...@googlegroups.com
2MB就不爽了,随便用chrome打开个网页,看看它会用几十MB去显示那几行字和图片?就算Go用在智能手机,静态链接后的footprint
也不会比动态库 iOS的app 大多少。

2011/11/29 贤 曹 <cjmx...@gmail.com>:

土星五号

unread,
Nov 28, 2011, 11:55:33 PM11/28/11
to golang...@googlegroups.com
我希望能提供创建动态库,这样就可以把go应用于现有的c/c++项目,用go来写一些模块。

Wei guangjing

unread,
Nov 29, 2011, 12:41:10 AM11/29/11
to golang...@googlegroups.com
创建动态库的支持在我的计划中,当然要等Go 1发布,系统包稳定下来。
我很好奇,如果有了动态库支持,大家打算用动态库来做什么应用?

chai

unread,
Nov 29, 2011, 12:44:33 AM11/29/11
to golang...@googlegroups.com
计划支持的动态库是所有平台的, 还是只是Windows平台的?
--
chaishushan

Wei guangjing

unread,
Nov 29, 2011, 12:49:36 AM11/29/11
to golang...@googlegroups.com
在 2011年11月29日 下午1:44,chai <chais...@gmail.com> 写道:
> 计划支持的动态库是所有平台的, 还是只是Windows平台的?

当然是所有平台,不过会先实现Windows平台,再考虑所有平台的实现。

Marvin Guo

unread,
Nov 29, 2011, 2:26:16 AM11/29/11
to golang...@googlegroups.com
所以这也就是那个问题,Google自从发布Android, Chrome再也没什么大动作了。

一个语言,也仅仅停留在思想上。我不太明白
动态库会造成程序的不稳定和运行的不确定性,这是何道理?现在系统不都是这样吗?哪个不稳定了?


2011/11/29 Wei guangjing <vcc...@gmail.com>

mikespook

unread,
Nov 29, 2011, 2:48:32 AM11/29/11
to golang...@googlegroups.com
虽然 go 在许多处理上跟其他语言不太一样,但是例如让 go 编译器支持 extern “C” 之类的不复杂。如果在语言还没稳定的时候就增加这些依赖于语言本身的功能实现,到后面维护起来得不尝失啊!


土星五号

unread,
Nov 29, 2011, 7:56:22 AM11/29/11
to golang...@googlegroups.com
只是相比较而言,动态链接比静态链接更容易出现问题,比如:执行文件所加载的so(dll)更新或更旧,函数参数个数与执行文件支持的不同,或其它问题,那么容易导致崩溃。

晓强李

unread,
Jan 22, 2013, 2:27:18 AM1/22/13
to golang...@googlegroups.com
要是支持了希望你把这句话吃掉.不要主观臆断,所有操作系统都支持动态链接库技术,为什么?因为这种技术几乎无可替代.

在 2011年11月29日星期二UTC+8下午12时47分44秒,fango写道:

晓强李

unread,
Jan 22, 2013, 2:27:28 AM1/22/13
to golang...@googlegroups.com
要是支持了希望你把这句话吃掉.不要主观臆断,所有操作系统都支持动态链接库技术,为什么?因为这种技术几乎无可替代.

在 2011年11月29日星期二UTC+8下午12时47分44秒,fango写道:

steve wang

unread,
Jan 22, 2013, 2:59:25 AM1/22/13
to golang...@googlegroups.com
为什么这种技术无可替代呢?
这里指的"Go语言支持动态库"是指支持用Go语言编写的动态库。

steve wang

unread,
Jan 22, 2013, 2:59:36 AM1/22/13
to golang...@googlegroups.com
为什么这种技术无可替代呢?
这里指的"Go语言支持动态库"是指支持用Go语言编写的动态库。

On Tuesday, January 22, 2013 3:27:18 PM UTC+8, 晓强李 wrote:

minux

unread,
Jan 22, 2013, 3:04:13 AM1/22/13
to golang...@googlegroups.com

2013/1/22 晓强李 <xiaoqia...@gmail.com>
要是支持了希望你把这句话吃掉.不要主观臆断,所有操作系统都支持动态链接库技术,为什么?因为这种技术几乎无可替代.
Plan 9就不支持动态链接。Plan 9显然是属于所有操作系统中的一员。
而且在某种意义上说还是重要的一员,因为Go的三作者中两个来自Plan 9团队,而gc编译器
就是基于Plan 9的编译器的。

PS: Plan 9到现在还在开发哦,不是“死掉”的操作系统,而且它已经支持Raspberry Pi了,连FreeBSD
这样主流的Unix还没支持完全呢(FreeBSD-CURRENT不支持VFP11)
而且Plan 9不会支持动态连接库是可以肯定的。(感兴趣的自己查对应的文献)

在 2011年11月29日星期二UTC+8下午12时47分44秒,fango写道:
我觉得只要 Rob 和 Ken 对Go
还有控制,就不会直接支持动态库。他们一直都认为动态库会造成程序的不稳定和运行的不确定性,因为,你测试的库和用户运行的可以不同,程序依赖的库可能不存在或版本不同造成无法
运行,甚至在某些系统(不点名)可以骑劫DLL等。这些静态链接都可避免。

至少现在还没有必须支持动态库的必要。以后嘛,希望也不需要。


为啥都说Go不支持动态库呢?我已经一再强调了gccgo是支持创建动态库的,它编译的Go程序
是可以动态链接到libgo.so的。比如说它编译的hello world程序可是和gcc编译的大小类似的。 

甚至对于gc都有CL实现了动态链接的功能(https://codereview.appspot.com/6926049/),你要
是愿意可以自行打patch试用。(这些个CL实现的东西更进了一步,你可以在C语言中加载Go编写
的.so文件)所以说,技术瓶颈是没有的。(这个系列的CL应该不会原封不动的接受)

Bonly H

unread,
Jan 23, 2013, 9:10:15 PM1/23/13
to golang...@googlegroups.com
我觉得动态库以及与其它语言之间的相互调用(包括主C main,动态调go)应该以后都是要支持的.只是当务之急在不紧急任务栏罢了.

在 2011年11月29日星期二UTC+8上午11时17分39秒,Marvin Guo写道:

Alexander Sun

unread,
Jan 26, 2013, 3:52:13 AM1/26/13
to golang...@googlegroups.com
Minux,你参与的llgo有支持动态库的计划吗?现在用Go开发桌面程序有点麻烦(说语言定位不同的请见谅,Java不也是弄了好多桌面程序。)如果有动态库的支持,相信商业库会多很多。

还有,据目前找到的资料,gccgo编译的动态库还不怎么完善,返回值如果比较复杂,就很容易出错。

在 13-1-22,minux<minu...@gmail.com> 写道:
> 2013/1/22 晓强李 <xiaoqia...@gmail.com>
>
>> 要是支持了希望你把这句话吃掉.不要主观臆断,所有操作系统都支持动态链接库技术,为什么?因为这种技术几乎无可替代.
>
> Plan 9就不支持动态链接。Plan 9显然是属于所有操作系统中的一员。
> 而且在某种意义上说还是重要的一员,因为Go的三作者中两个来自Plan 9团队,而gc编译器
> 就是基于Plan 9的编译器的。
>
> PS: Plan 9到现在还在开发哦,不是“死掉”的操作系统,而且它已经支持Raspberry Pi了,连FreeBSD
> 这样主流的Unix还没支持完全呢(FreeBSD-CURRENT不支持VFP11)
> 而且Plan 9不会支持动态连接库是可以肯定的。(感兴趣的自己查对应的文献)
>
> 在 2011年11月29日星期二UTC+8下午12时47分44秒,fango写道:
>>>
>>> 我觉得只要 Rob 和 Ken 对Go
>>> 还有控制,就不会直接支持动态库。**他们一直都认为动态库会造成程序的不稳定和运行的不确定性,**因为,你测试的库和用户运行的可以不同,**
>>> 程序依赖的库可能不存在或版本不同造成无法
>>
>> 运行,**甚至在某些系统(不点名)可以骑劫DLL等。**这些静态链接都可避免。
>>>
>>> 至少现在还没有必须支持动态库的必要。以后嘛,希望也不需要。
>>>
>>
> 为啥都说Go不支持动态库呢?我已经一再强调了gccgo是支持创建动态库的,它编译的Go程序
> 是可以动态链接到libgo.so的。比如说它编译的hello world程序可是和gcc编译的大小类似的。
>
> 甚至对于gc都有CL实现了动态链接的功能(https://codereview.appspot.com/6926049/),你要
> 是愿意可以自行打patch试用。(这些个CL实现的东西更进了一步,你可以在C语言中加载Go编写
> 的.so文件)所以说,技术瓶颈是没有的。(这个系列的CL应该不会原封不动的接受)
>
> --
> --
> 官网: http://golang-china.org/
> IRC: irc.freenode.net #golang-china
> @golangchina
>
>
>
>

minux

unread,
Jan 26, 2013, 3:58:59 AM1/26/13
to golang...@googlegroups.com

2013/1/26 Alexander Sun <daeta...@gmail.com>

Minux,你参与的llgo有支持动态库的计划吗?现在用Go开发桌面程序有点麻烦(说语言定位不同的请见谅,Java不也是弄了好多桌面程序。)如果有动态库的支持,相信商业库会多很多。
llgo目前的程度还不到讨论动态库的问题
先期目标是把完整的Go语言都支持了,然后把runtime实现完整。

还有,据目前找到的资料,gccgo编译的动态库还不怎么完善,返回值如果比较复杂,就很容易出错。
不明白“返回值如果比较复杂“是啥意思。

Alexander Sun

unread,
Jan 26, 2013, 4:05:24 AM1/26/13
to golang...@googlegroups.com
返回值为字符串,很容易崩掉。单一的返回基本的值类型还可以。
多返回值还没测试过。

有机会也研究下llgo.

在 13-1-26,minux<minu...@gmail.com> 写道:

minux

unread,
Jan 26, 2013, 4:22:17 AM1/26/13
to golang...@googlegroups.com

2013/1/26 Alexander Sun <daeta...@gmail.com>
返回值为字符串,很容易崩掉。单一的返回基本的值类型还可以。
给个例子程序?因为正常情况下libgo整个都是动态链接的,我觉得这个
不太可能呀。
多返回值还没测试过。

晓强李

unread,
Jan 28, 2013, 3:18:08 AM1/28/13
to golang...@googlegroups.com
好吧,我确实不了解这个所谓的Plan 9这个千年试验品.

在 2013年1月22日星期二UTC+8下午4时04分13秒,minux写道:

晓强李

unread,
Jan 28, 2013, 3:24:19 AM1/28/13
to golang...@googlegroups.com
好吧比如说我有个很稳定的系统,只是现在缺少了一个插件,而它的插件是个.so(或者.dll),如何用go给其写插件.(这个系统可能是网络系统,所以不要说go只干网络的事儿,插件的事儿不管)

在 2013年1月22日星期二UTC+8下午3时59分36秒,steve wang写道:

晓强李

unread,
Jan 28, 2013, 3:32:41 AM1/28/13
to golang...@googlegroups.com
其实动态链接库代表者给开发者更好的自由,如果你觉得这些自由有可能使你变得放纵,那你可以严于律己的不使用这种自由带来的权利,而不是把自己困起来.另外,动态链接库的问题,通常是开发者的问题,或者版本管理的问题,而不是这种机制本身的问题.你说dll替换后版本不对导致崩溃,那么,一个没有经过严格测试的软件是如何上线的呢?

在 2013年1月22日星期二UTC+8下午3时59分25秒,steve wang写道:

minux

unread,
Jan 28, 2013, 10:54:36 AM1/28/13
to golang...@googlegroups.com

2013/1/28 晓强李 <xiaoqia...@gmail.com>
好吧,我确实不了解这个所谓的Plan 9这个千年试验品.
既然你说你不了解,就请不要轻易给人家定性 “千年试验品” 。
Plan 9是商用了的。比如Coraid公司的SR1521就是基于Plan 9的。

说得好像Plan 9是个玩具似的,这个上面也是做出了不少新东西的。比如它是最早支持
utf-8的(Ken和Rob发明utf-8就是给Plan 9用的);再比如Venti。

minux

unread,
Jan 28, 2013, 11:00:42 AM1/28/13
to golang...@googlegroups.com

2013/1/28 晓强李 <xiaoqia...@gmail.com>
好吧比如说我有个很稳定的系统,只是现在缺少了一个插件,而它的插件是个.so(或者.dll),如何用go给其写插件.(这个系统可能是网络系统,所以不要说go只干网络的事儿,插件的事儿不管)
前面我都说了有CL已经能让Go生成.so了。

我发现有些人就是为了争论而争论,这个功能有了你真的用么?你要是这么想用,怎么不
打patch自己试试呢?这里争论这个有啥用处呀。

在 2013年1月22日星期二UTC+8下午3时59分36秒,steve wang写道:
为什么这种技术无可替代呢?
这里指的"Go语言支持动态库"是指支持用Go语言编写的动态库。

On Tuesday, January 22, 2013 3:27:18 PM UTC+8, 晓强李 wrote:
要是支持了希望你把这句话吃掉.不要主观臆断,所有操作系统都支持动态链接库技术,为什么?因为这种技术几乎无可替代.

在 2011年11月29日星期二UTC+8下午12时47分44秒,fango写道:
我觉得只要 Rob 和 Ken 对Go
还有控制,就不会直接支持动态库。他们一直都认为动态库会造成程序的不稳定和运行的不确定性,因为,你测试的库和用户运行的可以不同,程序依赖的库可能不存在或版本不同造成无法运行,甚至在某些系统(不点名)可以骑劫DLL等。这些静态链接都可避免。

至少现在还没有必须支持动态库的必要。以后嘛,希望也不需要。

2011/11/29 mikespook <mike...@gmail.com>:
> go 对动态库的支持是通过 cgo。现在的“不支持”,我觉得只是一个狭义的说法。
>
> 另外,go显然并不准备直接取代 c。我觉得Go作为网络系统级语言这个定位很精准。
>

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
 
---
您收到此邮件是因为您订阅了 Google 网上论坛的“Golang-China”论坛。
要取消订阅此网上论坛,请发送电子邮件至 golang-china...@googlegroups.com
要查看更多选项,请访问 https://groups.google.com/groups/opt_out。
 
 

minux

unread,
Jan 28, 2013, 11:20:12 AM1/28/13
to golang...@googlegroups.com

2013/1/28 晓强李 <xiaoqia...@gmail.com>
其实动态链接库代表者给开发者更好的自由,如果你觉得这些自由有可能使你变得放纵,那你可以严于律己的不使用这种自由带来的权利,而不是把自己困起来.另外,动态链接库的问题,通常是开发者的问题,或者版本管理的问题,而不是这种机制本身的问题.你说dll替换后版本不对导致崩溃,那么,一个没有经过严格测试的软件是如何上线的呢?
请问你如何测试众多版本的插件?
就以你前面说的插件用动态库实现为例:
1. 用户用了插件之后,程序崩溃,责任怎么定?用户才不管是不是插件的问题呢,肯定是直接找主程序的厂商。
2. 你发布主程序的时候,真的会测试所有插件的版本么?会测试所有插件A的版本和插件B的版本的所有组合呢?
再说,你要是有很多插件,每个有诸多版本,该如何测试?(别忘了还有第三方插件呢)
别说只能让用户用最新版本(或者最新几个版本)的插件。这个肯定行不通的。除非你程序限定死了,但是如此
限定了之后,动态连接的意义何在?节约内存么?现代操作系统早都做到了不被引用的页面不加载到内存了。
3. 安全问题呢?动态连接可以导致很多安全问题。考虑过么?知道有哪些么?
4. 如果插件的开发者要求提供C++的插件接口,怎么办?如何做ABI兼容?做了C++接口,又要Java的了。
5. 插件机制是否要支持(不重启主软件的)卸载机制?怎么做?(事实上很多支持进程内插件的软件是不支持这
个功能的,为啥?)
6. 进程内插件的存在使得你必须维护所有有意或者无意导出的符号,这个如何管理?
是否每次接口改变都要改变名字?还是用symbol versioning?后者不是所有动态连接库平台都支持,怎么办?

与之相对的进程外插件的机制,通过严格定义的协议通信。这个方式是很适合Go的,比如gocode就是这么做的。

Kula

unread,
Jan 29, 2013, 3:43:31 AM1/29/13
to golang...@googlegroups.com
我一般把这种人叫troll. 他发言只是想引发大家激烈吵架而已。


2013/1/28 晓强李 <xiaoqia...@gmail.com>
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
 
---
您收到此邮件是因为您订阅了 Google 网上论坛的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到 golang-china...@googlegroups.com
要查看更多选项,请访问 https://groups.google.com/groups/opt_out。
 
 

Alexander Sun

unread,
Jan 28, 2013, 8:12:24 AM1/28/13
to golang...@googlegroups.com
貌似如果想要个靠谱的共享库,1-2年内,估计要爱好者自己动手了。。。(纯属臆测,不要认真。。。)

在 13-1-28,晓强李<xiaoqia...@gmail.com> 写道:

minux

unread,
Jan 29, 2013, 9:41:55 AM1/29/13
to golang...@googlegroups.com

2013/1/28 Alexander Sun <daeta...@gmail.com>

貌似如果想要个靠谱的共享库,1-2年内,估计要爱好者自己动手了。。。(纯属臆测,不要认真。。。)
都已经有人做了。

曹贤

unread,
Jan 29, 2013, 10:44:54 PM1/29/13
to golang...@googlegroups.com
我在这里想说的是某些人不知道他是一直热爱和还是迷信呢总是用各种借口来逃避别人的话题还怕别人说go存在的不足,我见了好多人你这不是对技术的热爱你是迷恋go而且是盲目的不科学的,go是用来做什么的?写代码的知道不你是码农,我们要的是什么?我们需要一个方便而又强大的开发语言来帮我们调高效率就这么简单别扯什么go还年轻啦 go不需要动态库拉 go等等废话,我看来go目前缺少的东西太多了基本就是个残缺品,我不是说go不好我也很看好它(虽然有些小小的失落感)我不想说go怎么定位怎么扯淡,我是码农我需要的是go的图形驱动 高效的运行效率 传说中的高并发 微线程 我需要静态的或动态库现在毛都没有所谓的静态库每次更新都要编译难道不能提供一个能直接静态链接的lib么? 这么基本的东西都没有你敢说他多牛逼么? .a文件 就是个屁 还有多态性现在这个说真用起来很不方便巨纠结..吐槽完毕虽然还有但是我不想说了我等吧.....


--

Oling Cat

unread,
Jan 30, 2013, 12:30:48 AM1/30/13
to Golang-China
前面已经有过回答了,你还在说,这是要干啥?minux的问题你还没回答呢,说这么长一堆明明是你在逃避问题好吧?Go是有很多不足,但社区都已经在努力改进了,这个时候你再说这一堆是要干啥?你真的要把“在你看来还很不成熟的Go”用在自己的项目中?另寻它路吧,C++欢迎您。
PS:这个thread大家还是mute掉吧,再讨论下去就是浪费时间了。如果有新的疑问,请重开一个话题。
OT:要不要教一下你怎么用逗号和句号= =?

--
Hello! This is Oling Cat!


2013/1/30 曹贤 <cjmx...@gmail.com>

chai2010

unread,
Jan 30, 2013, 2:30:06 AM1/30/13
to golang...@googlegroups.com
在 2013年1月30日下午1:30,Oling Cat <olin...@gmail.com>写道:
前面已经有过回答了,你还在说,这是要干啥?minux的问题你还没回答呢,说这么长一堆明明是你在逃避问题好吧?Go是有很多不足,但社区都已经在努力改进了,这个时候你再说这一堆是要干啥?你真的要把“在你看来还很不成熟的Go”用在自己的项目中?另寻它路吧,C++欢迎您。
那里都有喜欢这种争论的人, 没必要太认真.

其实也不是不许吐槽, 但是最好能带点干货.
不要总是: Go没有XXX功能, 连XXX都不如.
这是5毛句式, 一般人都不喜欢.

我在之前的一个类似的争论回过的, 
如果喜欢吐槽Go语言的能整一本<The golang haters handbook>出来,
这样也算是造福大家了.

PS:这个thread大家还是mute掉吧,再讨论下去就是浪费时间了。如果有新的疑问,请重开一个话题。
好像即使锁定, gmail用户还是能回复.



--
chaishushan
http://chaishushan.blog.163.com/

lihui

unread,
Jan 30, 2013, 3:54:35 AM1/30/13
to golang...@googlegroups.com
我觉得动不动说人是troll的,应该是属于毁谤。

2013/1/30 chai2010 <chais...@gmail.com>

Kula

unread,
Jan 30, 2013, 3:55:58 AM1/30/13
to golang...@googlegroups.com
我没有动不动就说..事实上离我最近一次说人troll已经过去三年了


2013/1/30 lihui <ustc....@gmail.com>

Ruiqi Hong

unread,
Jan 30, 2013, 4:16:13 AM1/30/13
to golang...@googlegroups.com
在 2013年1月30日上午11:44,曹贤 <cjmx...@gmail.com>写道:
我需要静态的或动态库现在毛都没有所谓的静态库每次更新都要编译难道不能提供一个能直接静态链接的lib么? 这么基本的东西都没有你敢说他多牛逼么? .a文件 就是个屁 



静态库每次更新都要编译?你从哪里看到的 

lihui

unread,
Jan 30, 2013, 5:16:09 AM1/30/13
to golang...@googlegroups.com
估计是跟我一样用的tip,好像是有这么回事,如果编译了新的gc,而没有重新编译原有的lib话会有不兼容。有次我玩revel就出现莫名其妙的错误,重新编译就好了,不知道稳定版是否也这样。

2013/1/30 Ruiqi Hong <hong...@gmail.com>
在 2013年1月30日上午11:44,曹贤 <cjmx...@gmail.com>写道:
我需要静态的或动态库现在毛都没有所谓的静态库每次更新都要编译难道不能提供一个能直接静态链接的lib么? 这么基本的东西都没有你敢说他多牛逼么? .a文件 就是个屁 



静态库每次更新都要编译?你从哪里看到的 

--

lihui

unread,
Jan 30, 2013, 5:17:33 AM1/30/13
to golang...@googlegroups.com
早期是直接报不兼容,现在好像不报了。

2013/1/30 lihui <ustc....@gmail.com>

Ruiqi Hong

unread,
Jan 30, 2013, 5:23:44 AM1/30/13
to golang...@googlegroups.com
哦,如果是这个问题,确实是
我在连接器的选项里看到了这一条
-f ignore version mismatch

Ruiqi Hong

unread,
Jan 30, 2013, 5:43:19 AM1/30/13
to golang...@googlegroups.com
./main.go:4: import /home/hongruiqi/go/pkg/windows_amd64/net/http.a: object is [windows amd64 devel +185eb42ac938 Wed Jan 30 01:55:02 2013 +0100 X:none] expected [windows amd64 devel +0d9fd828f099 Wed Jan 30 17:26:22 2013 +1100 X:none]
刚试了一下,还是会报错,似乎-f没有用
不过感觉这个不奇怪啊。

minux

unread,
Jan 30, 2013, 7:20:55 AM1/30/13
to golang...@googlegroups.com

2013/1/30 Ruiqi Hong <hong...@gmail.com>

./main.go:4: import /home/hongruiqi/go/pkg/windows_amd64/net/http.a: object is [windows amd64 devel +185eb42ac938 Wed Jan 30 01:55:02 2013 +0100 X:none] expected [windows amd64 devel +0d9fd828f099 Wed Jan 30 17:26:22 2013 +1100 X:none]
刚试了一下,还是会报错,似乎-f没有用
不过感觉这个不奇怪啊。
命令行是啥?这个是可以的:
go build -ldflags -f xxx

顺便说下,换了工具链重新编译是因为换了工具链.a (实际是里面的.5/.6/.8)的格式可能会变。
而且这个提示一般用户是不会经常遇到的,谁也不会经常换工具链吧?
经常更换工具链但是更新方式正常的用户也不会遇到。

Ruiqi Hong

unread,
Jan 30, 2013, 7:31:05 AM1/30/13
to golang...@googlegroups.com
我是在linux下先checkout旧版本,然后export GOOS=windows ./make.bash
然后checkout到tip,export GOOS=linux ./make.bash
此时linux的.a是新的,但是windows的仍然是旧的
然后export GOOS=windows,
go build -ldflags="-f" 或者 go build -ldflags -f
去编译一个main包

晓强李

unread,
Jan 30, 2013, 10:23:16 AM1/30/13
to golang...@googlegroups.com
我只陈述事实,而你这条好像更像争吵.

在 2013年1月29日星期二UTC+8下午4时43分31秒,郑伟写道:

晓强李

unread,
Jan 30, 2013, 10:37:14 AM1/30/13
to golang...@googlegroups.com
我说的很明白,不能因噎废食,而且动态库远没那么恐怖,君不见复杂的OS都是由动态库堆叠而且,所以当您使用着由动态库构成的OS和其他应用软件码下这个帖子的时候,请不要说动态库没有用处.或许像你们说的Plan9一样,没有动态库,但那前提是Plan9自己精巧的机制,残酷的现实是Linux,Mac OS,Windows...都得依赖动态库的特性.我说这么多无非想表达两个观点:
1) 我需要动态库,我觉得动态库很重要
2) 我希望golang能够更强大,更实用.
(场景:未来的某一天,PC机有几十个核心,畅快的奔跑着golang写出的大型游戏(或者别的神马东西),在goroutine的支持下流畅的画面,逼真的场景让人流连忘返,但是突然我需要更新某个模块....然后,然后就没有然后了.)

在 2013年1月29日星期二UTC+8上午12时20分12秒,minux写道:

minux

unread,
Jan 30, 2013, 11:20:20 AM1/30/13
to golang...@googlegroups.com

2013/1/30 晓强李 <xiaoqia...@gmail.com>
我说的很明白,不能因噎废食,而且动态库远没那么恐怖,君不见复杂的OS都是由动态库堆叠而且,所以当您使用着由动态库构成的OS和其他应用软件码下这个帖子的时候,请不要说动态库没有用处.或许像你们说的Plan9一样,没有动态库,但那前提是Plan9自己精巧的机制,残酷的现实是Linux,Mac OS,Windows...都得依赖动态库的特性.我说这么多无非想表达两个观点:
1) 我需要动态库,我觉得动态库很重要
我再重复一遍:已经有人实现了,patch都在那里,为啥还在这里争论动态库的好处呢?
你要是真的需要,至少去看看我说的patch吧? 
2) 我希望golang能够更强大,更实用.
(场景:未来的某一天,PC机有几十个核心,畅快的奔跑着golang写出的大型游戏(或者别的神马东西),在goroutine的支持下流畅的画面,逼真的场景让人流连忘返,但是突然我需要更新某个模块....然后,然后就没有然后了.)
难道更新软件只有动态库一种方式么?我前面也说了,使用动态库这种紧耦合的方式
构造软件也不一定是最好的方式;

最近有人在golang-nuts上从安全更新角度讨论动态链接库的必要性,建议自己去看看。
[go-nuts] Security downsides of static linking

Liigo Zhuang

unread,
Jan 31, 2013, 12:41:01 AM1/31/13
to golang...@googlegroups.com

你说的是对的,fango对两位老大的分析也是对的(因为他们表达过类似的意思)。go开发者都保守、偏执,认死理。喝口水还可能噎死人呢,都知道吸烟有害健康还是无数人吸,明明知道危害很大做化疗的人也数不胜数,平时都对抗生素唯恐避之不及,关键时候还得用它。回到动态链接库上,它在全世界全系统平台内都被广泛使用,你凭什么仅靠一些缺陷和偏见就判它死刑呢?

还有一点,go设计之初就考虑不周全,要支持动态链接恐怕会导致语言本身伤筋动骨大改,可能这才是他们拒绝的真实理由,其他都是借口。

Ruiqi Hong

unread,
Jan 31, 2013, 12:46:34 AM1/31/13
to golang...@googlegroups.com
minux大已经说了,已经有patch可以做了,还借口。。。

Liigo 这么讨厌go和开发团队,那还关注这个列表做什么。


Liigo Zhuang

unread,
Jan 31, 2013, 12:48:45 AM1/31/13
to golang...@googlegroups.com

你理解错误

Ruiqi Hong

unread,
Jan 31, 2013, 1:02:57 AM1/31/13
to golang...@googlegroups.com
在 2013年1月31日下午1:48,Liigo Zhuang <com....@gmail.com>写道:


在 2013-1-30 下午5:16,"Ruiqi Hong" <hong...@gmail.com>写道:


>
> 在 2013年1月30日上午11:44,曹贤 <cjmx...@gmail.com>写道:
>>
>> 我需要静态的或动态库现在毛都没有所谓的静态库每次更新都要编译难道不能提供一个能直接静态链接的lib么? 这么基本的东西都没有你敢说他多牛逼么? .a文件 就是个屁 
>>
>>
>
> 静态库每次更新都要编译?你从哪里看到的 
>

你理解错误

 
所以,你想表明什么?

Liigo Zhuang

unread,
Jan 31, 2013, 1:03:08 AM1/31/13
to golang...@googlegroups.com

有些人呢,看上去是golang爱好者、拥护者,却处处迁就、满足于现状,毫无进取心,接受不得新事物,这也反对那也不赞成,事实上他们已经成为golang发展进程中的绊脚石。(我这里说的“他们”,大概也包括golang三个创始人在内。)

Liigo Zhuang

unread,
Jan 31, 2013, 1:07:09 AM1/31/13
to golang...@googlegroups.com

我已经给你这类人下了定义,对号入座吧。你们这种人少点,也许golang会发展的更快更好。

在 2013-1-31 下午1:46,"Ruiqi Hong" <hong...@gmail.com>写道:

lihui

unread,
Jan 31, 2013, 1:20:34 AM1/31/13
to golang...@googlegroups.com
我觉得你对golang的期许太多了,golang就是想专注做好一些事情,而不是走向高大全。就目前而言,做系统管理、算法密集、以及业务模型不多的web应用还行。
做操作系统,数据库、企业应用之类的估计都够呛。

要玩语言特性,推荐玩scala,特别有趣,不过就是编译速度很坑爹。

2013/1/31 Liigo Zhuang <com....@gmail.com>

Liigo Zhuang

unread,
Jan 31, 2013, 1:35:34 AM1/31/13
to golang...@googlegroups.com


在 2013-1-31 下午1:46,"Ruiqi Hong" <hong...@gmail.com>写道:
>

> minux大已经说了,已经有patch可以做了,还借口。。。
>
> Liigo 这么讨厌go和开发团队,那还关注这个列表做什么。
>

知道 “劣币驱逐良币” 是怎么形成的吗?把不同意见的人都排挤走,你就得逞了!

{{有些人呢,看上去是golang爱好者、拥护者,却处处迁就、满足于现状,毫无进取心,接受不得新事物,排挤不同意见,这也反对那也不赞成,事实上他们已经成为golang发展进程中的绊脚石。 (我这里说的“他们”,大概也包括golang三个创始人在内。)}}

chai2010

unread,
Jan 31, 2013, 2:27:19 AM1/31/13
to golang...@googlegroups.com
在 2013年1月31日下午2:35,Liigo Zhuang <com....@gmail.com>写道:


在 2013-1-31 下午1:46,"Ruiqi Hong" <hong...@gmail.com>写道:
>
> minux大已经说了,已经有patch可以做了,还借口。。。
>
> Liigo 这么讨厌go和开发团队,那还关注这个列表做什么。
>

知道 “劣币驱逐良币” 是怎么形成的吗?把不同意见的人都排挤走,你就得逞了!

我来这个列表是为了学习Go语言的, 首要目的不是为了攻击它的各种缺点.
如果Go语言有这么多我不喜欢的缺点, 我就不会把时间浪费在它上面.

现在收到的很多都是骂街的邮件, 实在忍无可忍了!
你这才是  “劣币驱逐良币” 吧?

而且, 你这个观点应该发到golang-nuts上去, 
要点名golang的三个创始人已经成为golang发展进程中的绊脚石,
让他们赶快滚蛋.

你要是没能力让Rob Pike他们滚蛋, 那么建议你自己新建个列表吧.
我真的是不想再收到这类垃圾邮件了!



--

Kula

unread,
Jan 31, 2013, 4:37:36 AM1/31/13
to golang...@googlegroups.com
爱学学,不学滚


2013/1/31 chai2010 <chais...@gmail.com>

晓强李

unread,
Jan 31, 2013, 4:51:23 AM1/31/13
to golang...@googlegroups.com
额,Scala是不错,可惜要想学好Scala必须弄明白Java平台的东西(毕竟库还是借助Java的库),而我已经在.net平台上很熟溜了,C#虽然没有Scala那么甜,但已经非常甜了.各种特性都找得到.

在 2013年1月31日星期四UTC+8下午2时20分34秒,灵剑子写道:

晓强李

unread,
Jan 31, 2013, 4:51:33 AM1/31/13
to golang...@googlegroups.com
额,Scala是不错,可惜要想学好Scala必须弄明白Java平台的东西(毕竟库还是借助Java的库),而我已经在.net平台上很熟溜了,C#虽然没有Scala那么甜,但已经非常甜了.各种特性都找得到.

在 2013年1月31日星期四UTC+8下午2时20分34秒,灵剑子写道:
Reply all
Reply to author
Forward
0 new messages