最近在服务器（centos 7, gcc 7.2.0）上装软件时突然发现 在某个文件夹下不能编译软件，报错如下：
[root@localhost libXt-1.1.3]# ./configure --prefix=/share/soft/libXt-1.1.3 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/share/soft_backup/libXt-1.1.3': configure: error: C compiler cannot create executables #不能编译软件 See `config.log' for more details [root@localhost libXt-1.1.3]# gcc --version #怎么弄发现都报错 gcc: 错误：./specs：是一个目录 [root@localhost libXt-1.1.3]# gcc gcc: 错误：./specs：是一个目录
原因是：你在给\$LIBRARY_PATH:赋值时不小心多给了冒号 ”: ”，如：export LIBRARY_PATH=\$LIBRARY_PATH::/share/soft/readline-7.0/lib导致连续两个冒号之间没有目录，所以gcc就把当前路径当成库加载路径,导致报错，从一下可以看出：
[root@localhost libXt-1.1.3]# $LIBRARY_PATH #出现此问题时，我的LIBRARY_PATH如下，有 : : 从而导致报错 -bash: :/share/soft/readline-7.0/lib:/share/soft/libX11-1.5.0/lib:/share/soft/readline-7.0/lib: 没有那个文件或目录
pulldown-cmark has a toplevel directory named specs. A poorly configured LIBRARY_PATH, LPATH or GCC_EXEC_PREFIX may cause gcc to attempt to read this directory as a file.
Test to verify that this is the cause
Do this anywhere on your system.
\$ mkdir -p test/specs
\$ cd test
$ gcc –version
gcc: error: ./specs: Is a directory
(in a correctly-configured environment, this would, of course, simply print the version)
Ensure that the current directory is not listed in LIBRARY_PATH, LPATH, or GCC_EXEC_PREFIX.
Note that an empty entry is interpreted as the current directory, because that’s how POSIX defined PATH, and POSIX hates you. This means that these variables must not begin or end with :, and must not contain :: anywhere in the middle.
In my experience, this can easily occur as a result of the common pattern of using
to append paths to an environment variable without accidentally clobbering a pre-existing value. Needless to say, the very first time this is done it leaves an empty component at the end.
My suggestion is that you pick a file that you own where you modify the variable, and simply add a line to delete empty components after the fact. (this only needs to be done once, and as long as it is done at some point after the first path you add to the variable, it will work equally well regardless of whether VAR existed prior to the script)
# in e.g. .bashrc
# delete any possible empty components
VAR=\$(echo \$VAR | sed -E -e ‘s/^:*//’ -e ‘s/:*$//’ -e ‘s/:+/:/g’)