#26 Partial linking libtool

開啟中
unidan3 年之前創建 · 0 條評論
unidan commented 3 年之前

If you want to get libtool-for-shared-libraries into play, then the sensible thing IMHO would be to have libtool objects named .lo which themselves are created by two partial links: the non-PIC .o go into output.o, the PIC ones [._]libs/.o go into [._]libs/output.o.

Yes, Libtool does not do this ATM. This is a bug. I don't mind breaking compatibility here, as that hasn't worked well for a long time.

  • [llvm-dev] Make LLD output COFF relocatable object file (like ELF's -r does). How much work is required to implement this?

https://lists.llvm.org/pipermail/llvm-dev/2017-October/118094.html

  • Microsoft Portable Executable and Common Object File Format Specification

https://courses.cs.washington.edu/courses/cse378/03wi/lectures/LinkerFiles/coff.pdf

- https://lists.gnu.org/archive/html/automake/2006-03/msg00042.html - `/INCREMENTAL` in MSVC is the default and only incrementally link to shared object or executable. > If you want to get libtool-for-shared-libraries into play, then the sensible thing IMHO would be to have libtool objects named .lo which themselves are created by two partial links: the non-PIC *.o go into output.o, the PIC ones [._]libs/*.o go into [._]libs/output.o. > > Yes, Libtool does not do this ATM. This is a bug. I don't mind breaking compatibility here, as that hasn't worked well for a long time. - [llvm-dev] Make LLD output COFF relocatable object file (like ELF's -r does). How much work is required to implement this? https://lists.llvm.org/pipermail/llvm-dev/2017-October/118094.html - Microsoft Portable Executable and Common Object File Format Specification https://courses.cs.washington.edu/courses/cse378/03wi/lectures/LinkerFiles/coff.pdf - https://www.mail-archive.com/search?l=libtool@gnu.org&q=subject:%22Re%5C%3A+partial+linking%22&o=newest&f=1
Sign in to join this conversation.
未選擇標籤
未選擇里程碑
未指派成員
1 參與者
正在加載...
取消
保存
尚未有任何內容