linux/unix中soft link和hard link的区别是啥

Posted 2023-05-08

参考技术A 软链接 是对 文件的引用
硬链接 是对 设备的引用 参考技术B 1、hard link
由于linux系统中的文件系统是通过访问inode去查询数据资料的，所以硬链接就是指不同的两个文件名都指向一个inode，两个不会互相影响，删除一个还有另一个存在。链接数会变多。
2、symbolic link
符号连接就不一样了，比如文件A指向inode号123456，而文件B中的内容只是文件A的路径，所以不管打开A还是B最后都是访问A，有点像windows下的快捷方式，如果A被删除了，B就无法正常使用了。链接数不变。
总结：硬链接不能跨文件系统，不能连接目录。因为如果硬链接目录的话，那此目录下所有的文件都要建立硬链接，以后创建新文件时又要创建新硬链接，对于计算机来说太复杂。本回答被提问者和网友采纳

C++ Linking 找不到关于从 Unix 到 Linux 的项目迁移的库

【中文标题】C++ Linking 找不到关于从 Unix 到 Linux 的项目迁移的库

【英文标题】：C++ Linking cant find library on project migration from Unix to Linux

【发布时间】：2017-02-02 14:54:41

【问题描述】：

在解决了由于迁移导致的所有编译错误后，现在有库的链接器错误。

原始输出如下（项目中的一些名称由于显而易见的原因被替换）：

----------------------------------------------------------------
 (G) Linking module_name.o to make module_name
     LDOPTS set to:
  SHLIB Temp Path: /tmp/fbaSHLIBs020217035348fbamgr
     FBA libraries: -L/tmp/fbaSHLIBs020217035348fbamgr -lfba -lprocessControl
     Application libraries: -L/opt/app/fba/devl_rel_ver/bin/lib -lfba -lprojNameGenEdit -lprojNameTraceTool -lprojNameTables -lprojNameCommCcSc -lprojNamerecProc -lprojNameGenMap -lprojNameLogicalTracker -lprojNameCallCodes -lprojNameStrCodes -lprojNameFileVal -lprojNameReports -L -ltmi -L/opt/IBM/db2/V8.1/lib64  -ldb2
g++ -o module_name module_name.o \
                 \
                -I/opt/app/fba/devl_rel_ver/common \
                -L/tmp/fbaSHLIBs020217035348fbamgr -lfba -lprocessControl  \
                -L/opt/app/oraclnt/oracle/product/11.2.0.3/lib -lclntsh \
                `cat /opt/app/oraclnt/oracle/product/oraclient/lib/ldflags`  \
                `cat /opt/app/oraclnt/oracle/product/oraclient/lib/sysliblist` \
                -L/opt/app/fba/devl_rel_ver/bin/lib -lfba -lprojNameGenEdit -lprojNameTraceTool -lprojNameTables -lprojNameCommCcSc -lprojNamerecProc -lprojNameGenMap -lprojNameLogicalTracker -lprojNameCallCodes -lprojNameStrCodes -lprojNameFileVal -lprojNameReports -L$TMI_HOME -ltmi -L/opt/IBM/db2/V8.1/lib64  -ldb2
/usr/bin/ld: cannot find -lfba
collect2: ld returned 1 exit status
make: *** [module_name] Error 1

临时文件夹中的文件（也已完成上述名称替换）：

ls /tmp/fbaSHLIBs020217035348fbamgr
libfba.sl             libprojNameCallCodes.sl  libprojNameFileVal.sl  libprojNameGenMap.sl          libprojNamerecProc.sl  libprojNameStrCodes.sl  libprojNameTraceTool.sl
libprocessControl.sl  libprojNameCommCcSc.sl   libprojNameGenEdit.sl  libprojNameLogicalTracker.sl  libprojNameReports.sl  libprojNameTables.sl

我尝试了什么：

FBALIB = -L$(TEMP_SHLIB_DIR) $(TEMP_SHLIB_DIR)/libfba.sl $(TEMP_SHLIB_DIR)/libprocessControl.sl 列表项FBALIB = -L$(TEMP_SHLIB_DIR) -llibfba.sl -llibprocessControl.sl FBALIB = -L$(TEMP_SHLIB_DIR) -l$(TEMP_SHLIB_DIR)/libfba.sl -lprocessControl

没有任何效果！

请问，有什么我想念的想法吗？

【问题讨论】：

你有一个名为 libfba.so 的文件吗？

@MatiasValdenegro 不，只是找到了那个……为什么？像我展示的那样有 libfba.sl。

因为这是您使用 -lfba 时链接器查找的文件

不，那不行，好像.sl文件不是Linux共享库文件，你从哪里得到的？

"Unix" 只是“Unix”的许多不同变体和实现的通用名称。您从哪个特定的“Unix”移植？什么是*.sl 文件？这些文件与库有什么关系？您是否刚刚从另一个平台复制文件并尝试在您的 Linux 系统中使用它们而不进行任何类型的转换或重建？

【参考方案1】：

似乎 .sl 文件是 HP-UX 共享库，而 linux 使用 .so 扩展名作为共享库。看来您已将 HP-UX 库复制到 Linux，但这是行不通的。

唯一的解决方案是为 Linux 获取具有适当 .so 扩展名的等效库文件。