NO

Author Topic: Linker and libraries  (Read 11359 times)

czerny

  • Guest
Re: Linker and libraries
« Reply #15 on: March 12, 2013, 08:09:22 AM »
This is not the full truth. Both MS link and Polink know how to handle COMDAT sections ( COMDATs are described in the MS COFF docs ). Actually, the MSVC "function level linking" feature ( and also the "string pooling" thing ) are implemented by making use of such sections. In short: with COMDATs, it's possible that the linker uses certain sections of a module only - the rest won't become part of the final binary.
Would you please make a little example project using COMDAT sections?

japheth

  • Guest
Re: Linker and libraries
« Reply #16 on: March 12, 2013, 09:11:38 AM »
Would you please make a little example project using COMDAT sections?

A "project" is attached. It's for the command line only ( MAKE.BAT ) - it will need PATHs adjustments before running!

It needs PellesC and MS VC ( I used the free VC++ 2003 Toolkit ).

MS VC is used to create an object module/library that contains COMDATs.

Polink is used to create the final binary, IOW: it knows how to handle objects containing COMDATs and extracts the one function that is needed [ func2() ] from the ONE object module in the library.

Offline Vortex

  • Member
  • *
  • Posts: 797
    • http://www.vortex.masmcode.com
Re: Linker and libraries
« Reply #17 on: March 12, 2013, 07:43:54 PM »
Hi Japheth,

If I am not wrong, Masm does not support COMDAT. ( same for Poasm )

Checking the JWasm manual, I see that it supports this feature : 3.21 Segment Attribute COMDAT
Code it... That's all...

CommonTater

  • Guest
Re: Linker and libraries
« Reply #18 on: March 12, 2013, 07:47:15 PM »
Would you please make a little example project using COMDAT sections?

A "project" is attached. It's for the command line only ( MAKE.BAT ) - it will need PATHs adjustments before running!

It needs PellesC and MS VC ( I used the free VC++ 2003 Toolkit ).

MS VC is used to create an object module/library that contains COMDATs.

Polink is used to create the final binary, IOW: it knows how to handle objects containing COMDATs and extracts the one function that is needed [ func2() ] from the ONE object module in the library.

You may be correct ... However, that means going outside Pelles' toolchain, which you cannot do (not easily, at least) from within POIDE... It would require command line builds. 
 
So, while it might be true that POLINK can do this, it is equally true that PellesC cannot.
 
 

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2091
Re: Linker and libraries
« Reply #19 on: March 12, 2013, 08:04:05 PM »
MicroSoft Visual C++ no more (since 2005) support that /Gf enable string pooling (.data)
only /GF enable read-only string pooling (.rdata).
So it's quite useless now.
« Last Edit: March 21, 2013, 05:49:54 AM by timovjl »
May the source be with you

Offline Vortex

  • Member
  • *
  • Posts: 797
    • http://www.vortex.masmcode.com
Re: Linker and libraries
« Reply #20 on: March 12, 2013, 08:16:32 PM »
Hi timovjl,

This is why probably Japheth used the VC++ 2003 toolkit.
Code it... That's all...

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: Linker and libraries
« Reply #21 on: March 16, 2013, 11:08:36 AM »
I think that forcing everything into one source file isn't practical from a maintenance view.
Creating source files for groups of related functions seems much more strait forward to me.

Sure you would still end up with some functions that you don't need, but there is seldom a situation where you only need one function out of each group.
---
Stefan

Proud member of the UltraDefrag Development Team

czerny

  • Guest
Re: Linker and libraries
« Reply #22 on: May 22, 2013, 08:56:59 AM »
Hi timovjl,

This is why probably Japheth used the VC++ 2003 toolkit.
Does anyone know a working download link for this old toolkit?