本人在本地编写了一个go程序，使用了beego框架，环境如下：
[root@ test]# go version
go version go1.6 linux/amd64
[root@ test]# uname -a
Linux . 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
讲编译好的程序仍在了服务器上，main函数都没有进，就出来段错误，使用valgrind跟踪如下：
[root@slave5 MiGuLive-Serv]# valgrind ./test
==113607== Memcheck, a memory error detector
==113607== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==113607== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==113607== Command: ./t
==113607==
==113607==
==113607== Process terminating with default action of signal 11 (SIGSEGV)
==113607== Access not within mapped region at address 0x8
==113607== at 0x3C6EE0C957: _dl_map_object_deps (in /lib64/ld-2.12.so)
==113607== by 0x3C6EE0330F: dl_main (in /lib64/ld-2.12.so)
==113607== by 0x3C6EE15AED: _dl_sysdep_start (in /lib64/ld-2.12.so)
==113607== by 0x3C6EE014A3: _dl_start (in /lib64/ld-2.12.so)
==113607== by 0x3C6EE00B07: ??? (in /lib64/ld-2.12.so)
==113607== If you believe this happened as a result of a stack
==113607== overflow in your program's main thread (unlikely but
==113607== possible), you can try to increase the size of the
==113607== main thread stack using the --main-stacksize= flag.
==113607== The main thread stack size used in this run was 10485760.
==113607== Jump to the invalid address stated on the next line
==113607== at 0x486: ???
==113607== Address 0x486 is not stack'd, malloc'd or (recently) free'd
==113607==
==113607==
==113607== Process terminating with default action of signal 11 (SIGSEGV)
==113607== Bad permissions for mapped region at address 0x486
==113607== at 0x486: ???
==113607==
==113607== HEAP SUMMARY:
==113607== in use at exit: 0 bytes in 0 blocks
==113607== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==113607==
==113607== All heap blocks were freed -- no leaks are possible
==113607==
==113607== For counts of detected and suppressed errors, rerun with: -v
==113607== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 3)
Segmentation fault (core dumped)
服务器的环境如下：
[root@slave5]# uname -a
Linux slave5 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
比较奇怪的是，使用ldd命令检查程序的依赖
本地结果如下：
[root@ test]# ldd ./test
linux-vdso.so.1 => (0x00007fff612fe000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030f3200000)
libc.so.6 => /lib64/libc.so.6 (0x00000030f2e00000)
/lib64/ld-linux-x86-64.so.2 (0x00000030f2600000)
而上传到服务器上，结果却变成了如下：
[root@slave5 home]# ldd ./test
static linked
偶尔也出现
[root@slave5 home]# ldd test
/usr/bin/ldd: line 118: 120221 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"
而服务器上并不缺共享库，以前部署上去的go程序都可以正常跑。
补充说明： 在服务器上使用readelf -h命令查看elf文件头 本地是正常的，但到了服务器上就会出现 readelf: Error: no .dynamic section in the dynamic segment 为什么会这样？？
各位大侠，这是什么问题啊？求助！！！
