解决Visual C++ for Linux: -L"~/projects/path_to_lib_folder" 无法设置library search path的问题
2017-05-18 20:41
483 查看
最近倒腾Linux C/C++项目。以目前的情况来说,要生成编译(build)一个Linux工程脚本,首选的工具必定是CMake。这也是我之前Linux项目的首选。不过自从VS IDE支持Linux C/C++开发后,也尝试这通过一些小demo来体验MS的解决方案。总得来说还可以,但是有个大问题因为一直没时间搞,就没有深入。
这里通过一个假定的场景来说这个问题。
在VS Linux项目里,如果一个解决方案下面有多个工程,比方说有两个工程A(.out)和B(.so),当工程A依赖工程B时我们需要设置工程的依赖关系,保证编译工程A时能先把依赖库编译出来。设置方式如下图:
设置完依赖关系后还要保证编译A时能够链接到已经生成的libB.so。这需要在工程属性页里Configuration Properties / Linker / Input : Libraries Dependencies里加上B。当然这还不够,因为链接指定的是so的名字,并没有指定so的路径。所以,要找到so必须知道so文件在哪里。除了使用绝对路径外,更好的方案显然是指定库文件的目录。正常情况下,类库文件都会统一编译到一个指定的目录下。
在VS的环境里,本地$(SolutionDir)默认映射到远程的$(RemoteRootDir)。而$(RemoteRootDir)默认是"~/projects"。所以如果统一将二进制文件编译到$(SolutionDir)bin\$(Platform)\$(Configuration)的话,对应地,在远程Linux上会被部署在"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"目录下。于是通过属性页向Configuration Properties / Linker / General : Additional Library Directories添加"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"就从理论上解决了链接时-lB到哪里找libB.so的问题了。但是,经过尝试之后你会发现,这样做并没有解决链接时找不到libB.so的问题。
之前并没有长期做Linux开发,所以对GCC编译选项的使用也就主要花时间看了看各种警告选项。对于大小L的链接选项,也是一样,只是知道是干嘛,但是对于输入字串的格式是不是有严格要求还真不知道。于是,我就遇到了本文要说的这个问题。只要Additional Library Directories里的路径是通过"~"来定位的,就必然会遇到VS环境下编译时找不到库文件的问题(当然我并不清楚在Linux上直接使用GCC编译链接是不是会遇到同样的问题)。
要解决这个问题,要么向前文说的,使用绝对路径。这显然不是个好方法,特别是自定义的类库比较多的时候。另外一种方法是将"~"使用绝对路径替换。也就是说将$(RemoteRootDir)的值从"~/projects"改为"/home/user_name/projects"。这就得保证在多个机器上使用VS远程编译时机器上的用户名都是同一个,不然要不停地改,也是作孽。
其实最好的方法是将$(RemoteRootDir)改为"$HOME/projects"。
完~
这里通过一个假定的场景来说这个问题。
在VS Linux项目里,如果一个解决方案下面有多个工程,比方说有两个工程A(.out)和B(.so),当工程A依赖工程B时我们需要设置工程的依赖关系,保证编译工程A时能先把依赖库编译出来。设置方式如下图:
设置完依赖关系后还要保证编译A时能够链接到已经生成的libB.so。这需要在工程属性页里Configuration Properties / Linker / Input : Libraries Dependencies里加上B。当然这还不够,因为链接指定的是so的名字,并没有指定so的路径。所以,要找到so必须知道so文件在哪里。除了使用绝对路径外,更好的方案显然是指定库文件的目录。正常情况下,类库文件都会统一编译到一个指定的目录下。
在VS的环境里,本地$(SolutionDir)默认映射到远程的$(RemoteRootDir)。而$(RemoteRootDir)默认是"~/projects"。所以如果统一将二进制文件编译到$(SolutionDir)bin\$(Platform)\$(Configuration)的话,对应地,在远程Linux上会被部署在"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"目录下。于是通过属性页向Configuration Properties / Linker / General : Additional Library Directories添加"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"就从理论上解决了链接时-lB到哪里找libB.so的问题了。但是,经过尝试之后你会发现,这样做并没有解决链接时找不到libB.so的问题。
之前并没有长期做Linux开发,所以对GCC编译选项的使用也就主要花时间看了看各种警告选项。对于大小L的链接选项,也是一样,只是知道是干嘛,但是对于输入字串的格式是不是有严格要求还真不知道。于是,我就遇到了本文要说的这个问题。只要Additional Library Directories里的路径是通过"~"来定位的,就必然会遇到VS环境下编译时找不到库文件的问题(当然我并不清楚在Linux上直接使用GCC编译链接是不是会遇到同样的问题)。
要解决这个问题,要么向前文说的,使用绝对路径。这显然不是个好方法,特别是自定义的类库比较多的时候。另外一种方法是将"~"使用绝对路径替换。也就是说将$(RemoteRootDir)的值从"~/projects"改为"/home/user_name/projects"。这就得保证在多个机器上使用VS远程编译时机器上的用户名都是同一个,不然要不停地改,也是作孽。
其实最好的方法是将$(RemoteRootDir)改为"$HOME/projects"。
完~
相关文章推荐
- 在Linux上安装netcdf4 ,解决"Can't find or link to the hdf5 library"的问题
- hadoop 2.2 hbase "Unable to load native-hadoop library for your platform" 问题解决
- 基于hadoop 2.0 的hbase "Unable to load native-hadoop library for your platform" 问题解决
- 【原创】无法打开输入文件"***.lib"问题解决
- 解决安装Domino for Linux时配置的Web服务器无法启动的问题
- 解决WinForm中ComboBox控件的“设置"DataSourse”属性后无法修改项集合”以及两个不相关联的ComboxBox控件实现数据列表显示不可实现的问题
- 解决"由于不可识别问题,windows无法显示windows防火墙设置"的问题
- Project property "XFire services.xml path" does not refer to a valid file问题解决
- 解决系统集成中X无法启动waiting for X server to shut down FreeFontPath
- "ld: library not found for -lz.1.2.3"的问题解决
- Hibernate 级联保存时 偶尔会出现 "id to load is required for loading" 问题的解决办法
- Ruby on Rails: "无法启动此程序,因为计算机中丢失LIBMYSQL.dll"问题解决
- Java解析DBF文件,错误Failed to parse Number: For input string: "-.---" 或读取不出数据或乱码问题都在这里解决
- 解决eclipse搭建索爱sdk模拟程序时出现的"Couldn`t load zayitlib.dll library"问题
- 无法打开文件"LIBC.lib"问题解决
- The Folder Path "XXXX" Contains an Invalid Character 问题的另一个解决办法
- "ld: library not found for -l...." 问题的解决
- 解决 Linux下oracle导入(imp)导出(exp)出现"failed to open ...for reader/wirte" 错误
- "... 无法下载Silverlight应用程序。请查看Web服务器设置." 问题的解决方法
- linux 链接库文件出现“undefined reference to" 问题的解决方法