Java程序启动报如下错误

编程语言空心菜 回复了问题 • 2 人关注 • 1 个回复 • 25 次浏览 • 5 天前 • 来自相关话题

golang静态编译

编程语言Ansible 发表了文章 • 0 个评论 • 156 次浏览 • 2020-04-30 09:43 • 来自相关话题

golang 的编译(不涉及 cgo 编译的前提下)默认使用了静态编译,不依赖任何动态链接库。

这样可以任意部署到各种运行环境,不用担心依赖库的版本问题。只是体积大一点而已,存储时占用了一点磁盘,运行时,多占用了一点内存。早期动态链接库的产生,是因为早期的系统的内存资源十分宝贵,由于内存紧张的问题在早期的系统中显得更加突出,因此人们首先想到的是要解决内存使用效率不高这一问题,于是便提出了动态装入的思想。也就产生了动态链接库。在现在的计算机里,操作系统的硬盘内存更大了,尤其是服务器,32G、64G 的内存都是最基本的。可以不用为了节省几百 KB 或者1M,几 M 的内存而大大费周折了。而 golang 就采用这种做法,可以避免各种 so 动态链接库依赖的问题,这点是非常值得称赞的。
 
显示指定静态编译方法
在Docker化的今天, 我们经常需要静态编译一个Go程序,以便方便放在Docker容器中。 即使你没有引用其它的第三方包,只是在程序中使用了标准库net,你也会发现你编译后的程序依赖glic,这时候你需要glibc-static库,并且静态连接。

不同的Go版本下静态编译方式还有点不同,在go 1.10下, 下面的方式会尽可能做到静态编译:
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' .
原文: http://suo.im/6d3eun   查看全部
golang 的编译(不涉及 cgo 编译的前提下)默认使用了静态编译,不依赖任何动态链接库。

这样可以任意部署到各种运行环境,不用担心依赖库的版本问题。只是体积大一点而已,存储时占用了一点磁盘,运行时,多占用了一点内存。早期动态链接库的产生,是因为早期的系统的内存资源十分宝贵,由于内存紧张的问题在早期的系统中显得更加突出,因此人们首先想到的是要解决内存使用效率不高这一问题,于是便提出了动态装入的思想。也就产生了动态链接库。在现在的计算机里,操作系统的硬盘内存更大了,尤其是服务器,32G、64G 的内存都是最基本的。可以不用为了节省几百 KB 或者1M,几 M 的内存而大大费周折了。而 golang 就采用这种做法,可以避免各种 so 动态链接库依赖的问题,这点是非常值得称赞的。
 
显示指定静态编译方法
在Docker化的今天, 我们经常需要静态编译一个Go程序,以便方便放在Docker容器中。 即使你没有引用其它的第三方包,只是在程序中使用了标准库net,你也会发现你编译后的程序依赖glic,这时候你需要glibc-static库,并且静态连接。

不同的Go版本下静态编译方式还有点不同,在go 1.10下, 下面的方式会尽可能做到静态编译:
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' .

原文: http://suo.im/6d3eun  

php添加pdo_mysql模块报错

编程语言空心菜 回复了问题 • 2 人关注 • 1 个回复 • 3117 次浏览 • 2017-12-18 00:15 • 来自相关话题

分享Python基础入门到精通视频教程5套

编程语言alber1986 发表了文章 • 0 个评论 • 1472 次浏览 • 2017-12-16 11:32 • 来自相关话题

 
分享Python基础入门到精通视频教程5套:
第一套:Python14期VIP视频
第二套 python全栈开发工程师1期
第三套 2017年老男孩全栈第二期103天完整
第四套 Python视频课程就业班
第五套 Python自动化开发12期完整版
http://www.sucaihuo.com/video/194.html 查看全部

 
分享Python基础入门到精通视频教程5套:
第一套:Python14期VIP视频
第二套 python全栈开发工程师1期
第三套 2017年老男孩全栈第二期103天完整
第四套 Python视频课程就业班
第五套 Python自动化开发12期完整版
http://www.sucaihuo.com/video/194.html

如何确认我apache加载的php的真实路径

编程语言OS小编 回复了问题 • 2 人关注 • 1 个回复 • 1504 次浏览 • 2017-12-13 17:13 • 来自相关话题

python3: error while loading shared libraries: libpython3.5m.so.1.0

编程语言空心菜 回复了问题 • 2 人关注 • 1 个回复 • 3713 次浏览 • 2017-09-25 17:04 • 来自相关话题

编译php的imagick模块报错

编程语言空心菜 回复了问题 • 2 人关注 • 1 个回复 • 1843 次浏览 • 2017-09-24 12:04 • 来自相关话题

Go Web框架gin vs echo

编程语言koyo 发表了文章 • 0 个评论 • 3669 次浏览 • 2017-09-10 20:36 • 来自相关话题

Web框架类型

web框架的主流,是采用轻量级的中间件式框架,把网站变成只有api的一个个小服务,其他都扔到cdn之类的地方处理。

这种方式,开发快速、拼装能力强,要什么就加什么,不要的就不加,就像是乐高玩具,大受欢迎。

问题在于,这种框架有一堆,到底该选哪个。

Gin vs Echo

在golang中,这种杰出代表,有2个:gin 和 echo。

这两个框架,在同类中,路由性能最高,超出其他框架一大截。google了一大堆英文站,也没有找到这两个框架的比较。于是,在我们实际使用后,提供个比较。

先说结论:
如果你代表企业,最好选择gin,无痛开发。如果是个人,开发个轻量服务,哪怕echo有点小问题,你也觉得没啥,那么,就用echo。
 
下面是开始进行比较。

框架成熟度

gin完胜
gin拥有详尽的出错信息,极为方便调试。这非常关键。团队项目,这个更加重要。echo在这方面,就略微逊色。使用框架的第一天,就遇到了明明路由语法写错了,却不报错、不给结果,也没有任何提示的情况。
 

路由性能

gin微弱小胜
gin的卖点,是所有web框架中,路由性能最好。echo的卖点,是它的路由性能,比gin还好10%。
 
国外实际测试结果是:echo只在空路由时,性能比gin好10%。而常用的各种带参数路由,echo其实要输给gin约5-10%。

echo给出和其他框架的对比




最新详尽对比:https://github.com/gin-gonic/gin/issues/329  
 

路由便利、灵活性

一回事,都有点小不便:
两个路由采用同一种算法,这种算法性能很高,但有个缺点: 不支持路由排序,会认为是路由冲突。比如: 路由Get("/name")和 Get("/:id") ,一般来说,只要把Get("/name")放在Get("/:id")前面,就是不冲突的。路由模块,会先尝试匹配前面那个,没匹配上,再去匹配后面的。而 gin和echo用的路由模块,会认为这两个路由是冲突的。gin会给出提醒,不让编译通过;echo完全不提醒,冲突就冲突了。。。
这给路由起名、设计,带来了一些麻烦。

框架的可持续发展

两个都不够好。
gin的主创是2个大学生。每年寒暑假就频繁更新,快到期末考试了,就完全不更新了。两人不在的时候,有网友在帮忙热情的维护,但主要是修bug、整理中间件。框架本身的发展,还是靠主创寒暑假爆发。就是这样的框架,连csico都在用。。。好在,gin的代码注释量大,易读性高,便于其他人参与。而且包装中间件,也超级容易。作者本人的态度是,对于一个在github上,start达到5000+的项目,他怎么可能会不去维护。请大家放心使用,到寒暑假了,他自然会去更新。。。echo则是主创当前处于活跃状态,并且乐呵呵的想要开发2.0版。由于主创活跃,它自带了一些流行功能,比如websocket, http2, jwt授权。用gin的话,这些功能要自己包装个中间件,虽然也很容易就是了。但echo的问题在于,它的代码毫无注释。作者现在是在劲头上,等3-6个月,在路上看到个穿超短的妹子,热情转移了,很快就会忘记当时代码是怎么写的。没有注释,不但别人不方便接手,自己也懒得再去看,于是慢慢就永不再更新。缺少注释的开源包,大部分都有这个问题。echo最终会不会变成这个结局,我们无从得知。
 

总结

综上
echo的状态是当下主创本人活跃,框架还不太成熟,适合最轻量级服务;gin则是整体成熟、易于调试,但可以预期,框架本身发展不会太快,除非主创大学毕业,从事和golang相关的工作。echo的使用方式、命名,都参考了gin,两者很接近,切换框架很容易,所以不用担心选错。
 
更新
由于echo的路由冲突频繁且没有调试信息,目前不是合理选择。等作者补上了路由冲突检测,那么就还不错。
 
如果想要回避这种框架的路由冲突,又想享受类似的优秀,neo框架目前最接近.
 
原文地址:https://www.golangtc.com/t/56a38761b09ecc083100010c  查看全部


Web框架类型


web框架的主流,是采用轻量级的中间件式框架,把网站变成只有api的一个个小服务,其他都扔到cdn之类的地方处理。

这种方式,开发快速、拼装能力强,要什么就加什么,不要的就不加,就像是乐高玩具,大受欢迎。

问题在于,这种框架有一堆,到底该选哪个。


Gin vs Echo


在golang中,这种杰出代表,有2个:gin 和 echo。

这两个框架,在同类中,路由性能最高,超出其他框架一大截。google了一大堆英文站,也没有找到这两个框架的比较。于是,在我们实际使用后,提供个比较。

先说结论:
  • 如果你代表企业,最好选择gin,无痛开发。
  • 如果是个人,开发个轻量服务,哪怕echo有点小问题,你也觉得没啥,那么,就用echo。

 
下面是开始进行比较。


框架成熟度


gin完胜
  • gin拥有详尽的出错信息,极为方便调试。
  • 这非常关键。团队项目,这个更加重要。
  • echo在这方面,就略微逊色。使用框架的第一天,就遇到了明明路由语法写错了,却不报错、不给结果,也没有任何提示的情况。

 


路由性能


gin微弱小胜
  • gin的卖点,是所有web框架中,路由性能最好。
  • echo的卖点,是它的路由性能,比gin还好10%。

 
国外实际测试结果是:echo只在空路由时,性能比gin好10%。而常用的各种带参数路由,echo其实要输给gin约5-10%。

echo给出和其他框架的对比
GoAPI.png

最新详尽对比:https://github.com/gin-gonic/gin/issues/329  
 


路由便利、灵活性


一回事,都有点小不便:
  • 两个路由采用同一种算法,这种算法性能很高,但有个缺点: 不支持路由排序,会认为是路由冲突。
  • 比如: 路由Get("/name")和 Get("/:id") ,一般来说,只要把Get("/name")放在Get("/:id")前面,就是不冲突的。路由模块,会先尝试匹配前面那个,没匹配上,再去匹配后面的。
  • 而 gin和echo用的路由模块,会认为这两个路由是冲突的。gin会给出提醒,不让编译通过;echo完全不提醒,冲突就冲突了。。。

这给路由起名、设计,带来了一些麻烦。


框架的可持续发展


两个都不够好。
  • gin的主创是2个大学生。每年寒暑假就频繁更新,快到期末考试了,就完全不更新了。两人不在的时候,有网友在帮忙热情的维护,但主要是修bug、整理中间件。框架本身的发展,还是靠主创寒暑假爆发。就是这样的框架,连csico都在用。。。
  • 好在,gin的代码注释量大,易读性高,便于其他人参与。而且包装中间件,也超级容易。
  • 作者本人的态度是,对于一个在github上,start达到5000+的项目,他怎么可能会不去维护。请大家放心使用,到寒暑假了,他自然会去更新。。。
  • echo则是主创当前处于活跃状态,并且乐呵呵的想要开发2.0版。由于主创活跃,它自带了一些流行功能,比如websocket, http2, jwt授权。用gin的话,这些功能要自己包装个中间件,虽然也很容易就是了。
  • 但echo的问题在于,它的代码毫无注释。作者现在是在劲头上,等3-6个月,在路上看到个穿超短的妹子,热情转移了,很快就会忘记当时代码是怎么写的。没有注释,不但别人不方便接手,自己也懒得再去看,于是慢慢就永不再更新。
  • 缺少注释的开源包,大部分都有这个问题。echo最终会不会变成这个结局,我们无从得知。

 


总结


综上
  • echo的状态是当下主创本人活跃,框架还不太成熟,适合最轻量级服务;
  • gin则是整体成熟、易于调试,但可以预期,框架本身发展不会太快,除非主创大学毕业,从事和golang相关的工作。
  • echo的使用方式、命名,都参考了gin,两者很接近,切换框架很容易,所以不用担心选错。

 
更新
由于echo的路由冲突频繁且没有调试信息,目前不是合理选择。等作者补上了路由冲突检测,那么就还不错。
 
如果想要回避这种框架的路由冲突,又想享受类似的优秀,neo框架目前最接近.
 
原文地址:https://www.golangtc.com/t/56a38761b09ecc083100010c 

使用phpize安装redis扩展报错

编程语言Something 回复了问题 • 2 人关注 • 1 个回复 • 1798 次浏览 • 2017-08-22 19:01 • 来自相关话题

安装PHP编译出错合集记录

编程语言push 发表了文章 • 0 个评论 • 1343 次浏览 • 2017-06-15 19:08 • 来自相关话题

情况一:

-liconv -o sapi/fpm/php-fpm

/usr/bin/ld: cannot find -liconv

collect2: ld returned 1 exit status

make: *** [sapi/fpm/php-fpm] Error 1

初步定位是iconv的问题,解决方法 把libiconv卸载掉,进入libiconv源码目录执行:
# make uninstall
# make clean

# ./configure –prefix=/usr/local/libiconv
# make
# make install再进入php源码目录:
./configure php 时加上参数 --with-iconv=/usr/local/libiconv
情况二:

/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

解决办法安装包如下:
# yum install libtool-ltdl.x86_64 libtool-ltdl-devel.x86_64
情况三:

collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

解决办法, 请安装lib所需的安装包:
yum install ntp vim-enhanced gcc gcc-c++ gcc-g77 flex bison autoconf automake bzip2-devel ncurses-devel zlib-devel libjpeg-devel libpng-devel libtiff-devel freetype-devel libXpm-devel gettext-devel pam-devel kernel执行安装完以后即可解决问题make && make install
情况四:
ext/iconv/iconv.o: In function `php_iconv_stream_filter_ctor’:
/usr/local/soft/php-5.2.14/ext/iconv/iconv.c:2491: undefined reference to `libiconv_open’
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1编译参数如下:
./configure –prefix=/usr/local/php –with-gd=/usr/local/gd –with-jpeg-dir=/usr/local/jpeg –with-png-dir=/usr/local/png –with-freetype-dir=/usr/local/freetype –with-mysql=/usr/local/mysql –enable-fastcgi –enable-fpm解决办法:
增加   --disable-cli 编译参数。
 
情况五:

ext/xmlreader/php_xmlreader.o: In function `zim_xmlreader_XML':
/usr/local/src/php-5.2.8/ext/xmlreader/php_xmlreader.c:1109: undefined reference to `xmlTextReaderSetup'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

解决办法:折腾了半天,最后先make clean 一下,然后把所有libxml2相关的包都装上重新编译就ok了。
 
情况六:
运行可能报错 :我遇到xsl和mcrypt两个库报错,重新安装一下xsl的dev包就可以:CentOS : yum install libxslt-devel libmcrypt-devel
Debian : apt-get install libxslt1-dev libmcrypt-dev 如果你有其他的库不满足,搜索一下该库,安装一下即可,这一步应该没有太多问题。
编译:make 
 
我在Debian下make正常,但在CentOS下却提示make错误,
make: *** [sapi/fpm/php-fpm] Error 1 错误中出现 libiconv,应该是iconv包问题,
使用下面的命令替换即可:
make ZEND_EXTRA_LIBS='-liconv' 
完成后:make test
make install 查看全部
情况一


-liconv -o sapi/fpm/php-fpm

/usr/bin/ld: cannot find -liconv

collect2: ld returned 1 exit status

make: *** [sapi/fpm/php-fpm] Error 1


初步定位是iconv的问题,解决方法 把libiconv卸载掉,进入libiconv源码目录执行:
# make uninstall
# make clean

# ./configure –prefix=/usr/local/libiconv
# make
# make install
再进入php源码目录:
./configure php 时加上参数 --with-iconv=/usr/local/libiconv

情况二:


/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1


解决办法安装包如下:
# yum install libtool-ltdl.x86_64 libtool-ltdl-devel.x86_64

情况三:


collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1


解决办法, 请安装lib所需的安装包:
yum install ntp vim-enhanced gcc gcc-c++ gcc-g77 flex bison autoconf automake bzip2-devel ncurses-devel zlib-devel libjpeg-devel libpng-devel libtiff-devel freetype-devel libXpm-devel gettext-devel pam-devel kernel
执行安装完以后即可解决问题
make  && make install

情况四:
ext/iconv/iconv.o: In function `php_iconv_stream_filter_ctor’:
/usr/local/soft/php-5.2.14/ext/iconv/iconv.c:2491: undefined reference to `libiconv_open’
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
编译参数如下:
./configure –prefix=/usr/local/php –with-gd=/usr/local/gd –with-jpeg-dir=/usr/local/jpeg –with-png-dir=/usr/local/png –with-freetype-dir=/usr/local/freetype –with-mysql=/usr/local/mysql –enable-fastcgi –enable-fpm
解决办法:
增加   --disable-cli 编译参数。
 
情况五:


ext/xmlreader/php_xmlreader.o: In function `zim_xmlreader_XML':
/usr/local/src/php-5.2.8/ext/xmlreader/php_xmlreader.c:1109: undefined reference to `xmlTextReaderSetup'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1


解决办法:折腾了半天,最后先make clean 一下,然后把所有libxml2相关的包都装上重新编译就ok了。
 
情况六:
运行可能报错 :我遇到xsl和mcrypt两个库报错,重新安装一下xsl的dev包就可以:
CentOS : yum install libxslt-devel libmcrypt-devel 
Debian : apt-get install libxslt1-dev libmcrypt-dev
如果你有其他的库不满足,搜索一下该库,安装一下即可,这一步应该没有太多问题。
编译:make 
 
我在Debian下make正常,但在CentOS下却提示make错误,
make: *** [sapi/fpm/php-fpm] Error 1 错误中出现 libiconv,应该是iconv包问题,
使用下面的命令替换即可:
make ZEND_EXTRA_LIBS='-liconv' 
完成后:
make test
make install