Can an optional DLL take precedence over a fallback/default DLL?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Can an optional DLL take precedence over a fallback/default DLL?

Mads Dyrholm
Hi,

  I am using mingw to generate a DLL like this:

     $(CC) -shared -o foo.dll foo.o blas.dll lapack.dll -Wl,--out-implib,libbdca.a -lgfortran

  ... so it is depending on the contents of blas.dll and lapack.dll. It works perfectly for my application, but what if I later want to use another lapack or blas dll with a different name than provided on the above link command? - would it be possible to use my foo.dll with, say, "optimizedlapack.dll" instead of "lapack.dll" without re-linking foo.dll ?

Best regards, and mingw really rocks!!

    / Mads


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Can an optional DLL take precedence over afallback/default DLL?

Brian Dessent
Mads Dyrholm wrote:

>   ... so it is depending on the contents of blas.dll and lapack.dll.
> It works perfectly for my application, but what if I later want to use
> another lapack or blas dll with a different name than provided on the
> above link command? - would it be possible to use my foo.dll with,
> say, "optimizedlapack.dll" instead of "lapack.dll" without re-linking
> foo.dll ?

Not as written, because when you link to a DLL its name is encoded into
the import section of the resulting binary.  It's possible to do this
but you'd have to rewrite your code such that you dynamically access the
library at runtime with LoadLibrary() and only call routines in it
through function pointers obtained by GetProcAddress().

Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Can an optional DLL take precedence over afallback/default DLL?

Mads Dyrholm

Not as written, because when you link to a DLL its name is encoded into
the import section of the resulting binary.  It's possible to do this
but you'd have to rewrite your code such that you dynamically access the
library at runtime with LoadLibrary() and only call routines in it
through function pointers obtained by GetProcAddress().

Hmm, so providing a DLL is really different from providing a static library:

Imaginary DLL scenario:

1) foo.o uses blas routines found in blas.dll.
2) foobar.dll contains foo.o and bar.o
3) An application linked with foobar.dll (not using LoadLibrary) will depend on the blas routines found in blas.dll and nowhere else.

Imaginary static scenario:

1) foo.o uses blas routines found in blas.a
2) foobar.a contains foo.o and bar.o
3) An application linked with foobar.a will depend on blas routines, but the can come from any library, say useroptimizedblas.a

... so, providing a static library seems to be more useful to the user receiving the library (unless some LoadLibrary magic is done in the DLL scenario).

Any input / opinions on this?

   - Mads


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Can an optional DLL take precedence over afallback/default DLL?

Greg Chicares
On 2008-10-21 16:10Z, Mads Dyrholm wrote:
>
> 1) foo.o uses blas routines found in blas.a
> 2) foobar.a contains foo.o and bar.o
> 3) An application linked with foobar.a will depend on blas routines, but the
> can come from any library, say useroptimizedblas.a

That dependency is resolved at link time, not at run time.

With dynamic linking, an application is bound to the '.dll' file's name.
With  static linking, an application   contains  the  '.a'  file's code.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Can an optional DLL take precedence overafallback/default DLL?

Brian Dessent
In reply to this post by Mads Dyrholm
Mads Dyrholm wrote:

> Imaginary DLL scenario:
>
> 1) foo.o uses blas routines found in blas.dll.
> 2) foobar.dll contains foo.o and bar.o
> 3) An application linked with foobar.dll (not using LoadLibrary) will
> depend on the blas routines found in blas.dll and nowhere else.
>
> Imaginary static scenario:
>
> 1) foo.o uses blas routines found in blas.a
> 2) foobar.a contains foo.o and bar.o
> 3) An application linked with foobar.a will depend on blas routines,
> but the can come from any library, say useroptimizedblas.a
>
> ... so, providing a static library seems to be more useful to the user
> receiving the library (unless some LoadLibrary magic is done in the
> DLL scenario).
>
> Any input / opinions on this?

I don't see how it's all that meaningful to compare the two.  Static
libraries are just raw object files, they have not been linked and are
not executable.  So unless your user that you are distributing the
library to is a developer and has developer tools installed they will
not have any use for a static library.  But if they're a developer then
the problem that you originally started the thread with (that once
linked, an executable contains the DLL name hardcoded) also doesn't
exist, because they can just relink against the new DLL if they want to
change it out with a different implementation.

Or stated differently: if you need to ship binaries to the end user then
the issue is moot, because you either statically link a BLAS library
into your executable or you link to a BLAS DLL and ship that along side
the executable.  Either way, there is no way for the user to switch
implementations (unless the replacement implementation is a DLL of the
exact same name.)  The fact that a static library is in an intermediate
form that has not yet been finalized and thus has a little bit more
flexibility doesn't really change the situation.

Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Can an optional DLL take precedence overafallback/default DLL?

Mads Dyrholm

I don't see how it's all that meaningful to compare the two.  Static
libraries are just raw object files, they have not been linked and are
not executable.  So unless your user that you are distributing the
library to is a developer and has developer tools installed they will
not have any use for a static library.  But if they're a developer then
the problem that you originally started the thread with (that once
linked, an executable contains the DLL name hardcoded) also doesn't
exist, because they can just relink against the new DLL if they want to
change it out with a different implementation.

Let me see if I get this right...  I give them a DLL and they can "relink" it without having the obj files? probably not right?  I think you mean: I give them the obj files and they can make their own DLL, correct?

Or stated differently: if you need to ship binaries to the end user then

Well, not an application. I need to ship a library to them, without giving them the source code. But I would like for them to be able to switch the BLAS when they finally link their application.

the issue is moot, because you either statically link a BLAS library
into your executable or you link to a BLAS DLL and ship that along side
the executable.  Either way, there is no way for the user to switch
implementations (unless the replacement implementation is a DLL of the
exact same name.)  The fact that a static library is in an intermediate
form that has not yet been finalized and thus has a little bit more
flexibility doesn't really change the situation.

thanks!

 /Mads

 


Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Can an optional DLL take precedenceoverafallback/default DLL?

Brian Dessent
Mads Dyrholm wrote:

> Let me see if I get this right...  I give them a DLL and they can
> "relink" it without having the obj files? probably not right?  I think
> you mean: I give them the obj files and they can make their own DLL,
> correct?

What I was saying was that if you are even considering that giving them
a static library is a possibility then they must necessarily be
developers -- which means there's a lot more flexibility compared to
distributing to end users where you don't have the option to give them
unlinked code.

> Well, not an application. I need to ship a library to them, without
> giving them the source code. But I would like for them to be able to
> switch the BLAS when they finally link their application.

Okay, that makes the question a lot more clear.  Yes, I agree that if
you want to achieve that (and you don't want to use the dynamic
approach) you'd have to distribute it as a static library.

Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users