Re: [Mingw-users] ignoring unresolved symbols in shared libraries

[Brian H. <bh...@lu...>]

Thanks.

I have a bit of a catch-22.  The module that will supply those definitions 
needs this library to link.

I'm not familiar with import libraries or def files.  Perhaps that is 
sufficient?

Basically, what I have here is a library.  Others will use this library to 
create a finished executable (driver) by linking to this library.  Some 
methods used by the library are unique to each driver.  Thats why I was 
having them supplied during linking of the final product.

-- Brian

At 02:29 PM 7/10/2008, Brian Dessent wrote:
>Brian Hawley wrote:
>
> > Despite repeated attempts, I have been unable to get these undefined
> > references to go away.
>
>It just doesn't work that way with PE.  There's no magic linker switch
>to change the way the Windows operating system works.  This is not ELF,
>and you can't expect ELF semantics.  You can't have undefined
>references; you must tell the linker the module name where each symbol
>will come from.  You said the user will provide the symbols in an
>object, but that's not what the linker needs to know.  It needs the name
>of the module -- the name of the .exe or .dll -- because that is what
>must go in the .idata section.  You can provide this with an import
>library, a def file, or by directly linking against the module.
>
>If you want something that emulates the ELF lazy binding semantics, try
>FlexDLL.
>
>Brian
>
>-------------------------------------------------------------------------
>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>Studies have shown that voting for your favorite open source project,
>along with a healthy diet, reduces your potential for chronic lameness
>and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users