Re: DLL naming conventions

Re: DLL naming conventions

[Tor Lillqvist]

"Charles S. Wilson" <cwilson@ece.gatech.edu> writes:

> 2) on interface (API/ABI) versioning
>  http://www.gnu.org/software/libtool/manual.html#Versioning

Note that this document talks about stuff that AFAIK requires
cooperation from the runtime dynamic linker, that it knows how to
search for a suitable version of a shared library. No such dynamic
linker on Win32, alas.

(Writing a Unix-like (or should one say ELF-like?) dynamic linker for
Win32 would be an interesting exercise, of course.)

--tml

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles S. Wilson]

Tor Lillqvist wrote:
> 
> "Charles S. Wilson" <cwilson@ece.gatech.edu> writes:
> 
> > 2) on interface (API/ABI) versioning
> >  http://www.gnu.org/software/libtool/manual.html#Versioning
> 
> Note that this document talks about stuff that AFAIK requires
> cooperation from the runtime dynamic linker, that it knows how to
> search for a suitable version of a shared library. No such dynamic
> linker on Win32, alas.
> 
> (Writing a Unix-like (or should one say ELF-like?) dynamic linker for
> Win32 would be an interesting exercise, of course.)

!!!! ????

There is *something* in the windows system that gets notified that
myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
*something* searches the file system according to the search path
described earlier in this thread, loads the dll into the executable
process's memeory space (rebasing the memory location if necessary), and
fixes up all the internal pointers to match the in-process virtual
memory location.

Isn't that considered a dynamic linker? (Whether you call that
*something* a dynamic linker or not is really immaterial.  The
*something* is a runtime loader, and that's what the reference above is
discussing)

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Gary V. Vaughan]

On Fri, Sep 01, 2000 at 09:46:28AM -0400, Charles S. Wilson wrote:
> Tor Lillqvist wrote:
> > 
> > "Charles S. Wilson" <cwilson@ece.gatech.edu> writes:
> > 
> > > 2) on interface (API/ABI) versioning
> > >  http://www.gnu.org/software/libtool/manual.html#Versioning
> > 
> > Note that this document talks about stuff that AFAIK requires
> > cooperation from the runtime dynamic linker, that it knows how to
> > search for a suitable version of a shared library. No such dynamic
> > linker on Win32, alas.
> > 
> > (Writing a Unix-like (or should one say ELF-like?) dynamic linker for
> > Win32 would be an interesting exercise, of course.)
> 
> !!!! ????
> 
> There is *something* in the windows system that gets notified that
> myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
> *something* searches the file system according to the search path
> described earlier in this thread, loads the dll into the executable
> process's memeory space (rebasing the memory location if necessary), and
> fixes up all the internal pointers to match the in-process virtual
> memory location.
> 
> Isn't that considered a dynamic linker? (Whether you call that
> *something* a dynamic linker or not is really immaterial.  The
> *something* is a runtime loader, and that's what the reference above is
> discussing)

Nope.  Tor is correct.  The libtool versioning system assumes that the
runtime loader is smart enough to choose the most recent compatible
version of each dll that an application was linked with.  Many of the
operating systems that libtool supports have different rules for how
to name these versions so that the runtime loader can do it's stuff.
Libtool maps the unified version number scheme it exposes to the user
onto the versioning rules for the host platform.  That is why it is
okay to have libc5 and libc6 in the same directory on your Linux box.
Infact I could have several incompatible versions of libc6 in my lib
directory, and the runtime loader would choose the newest one that is
binary compatible with the version that the application was originally
linked with.

Libtool doesn't version dll's on Windows correctly right now, it uses
the linux versioning scheme to calculate the numbers.  It should
probably name them after the oldest ``interface'' (see the document
quoted above) that the library fully supports.  That is, if you build
a dll using libtool's --version 5:4:3, you would get library2.dll
(this version is at interface 5, but fully supports the last 3
interfaces).  This gives the windows loader the best chance of finding
the newest binary compatible dll.

Unfortunately Windows makes no distinction between the application
search path and the library search path, so the scheme I propose is
still flawed =(O|  You might have a newer bugfixed binary compatible
version of the dll you need, but if it is further down the application
search path than the buggy version you originally linked with, you get
the broken version.  Nice one Bill...

Maybe Cygwin should put all of it's libtool built libraries (or any
others that are correctly versioned w.r.t the runtime loader) into a
single directory that is near the front of the default path.  /usr/lib
seems like a good place.

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles S. Wilson]

"Gary V. Vaughan" wrote:
> 
> Charles S. Wilson wrote:
> >
> > There is *something* in the windows system that gets notified that
> > myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
> > *something* searches the file system according to the search path
> > described earlier in this thread, loads the dll into the executable
> > process's memeory space (rebasing the memory location if necessary), and
> > fixes up all the internal pointers to match the in-process virtual
> > memory location.
> >
> > Isn't that considered a dynamic linker? (Whether you call that
> > *something* a dynamic linker or not is really immaterial.  The
> > *something* is a runtime loader, and that's what the reference above is
> > discussing)
> 
> Nope.  Tor is correct.  The libtool versioning system assumes that the
> runtime loader is smart enough to choose the most recent compatible
> version of each dll that an application was linked with.  Many of the
> operating systems that libtool supports have different rules for how
> to name these versions so that the runtime loader can do it's stuff.
> Libtool maps the unified version number scheme it exposes to the user
> onto the versioning rules for the host platform.  That is why it is
> okay to have libc5 and libc6 in the same directory on your Linux box.
> Infact I could have several incompatible versions of libc6 in my lib
> directory, and the runtime loader would choose the newest one that is
> binary compatible with the version that the application was originally
> linked with.

Hmmm....you can do this sort of thing -- in a limited way, of course --
with appropriate naming of the dll and importlib.  Recall that import
libs contain the hardcoded name of the dll for which they were built.

Also, there are two separate issues being discussed here: (1) how to
(compile-time) link against the 'right' version of a library, and (2)
how to insure that the 'right' dll is loaded at run-time.  In the first
case, 'right' just means the correct version that supports the necessary
interface; in the second case, 'right' means the correct version
compiled for the right environment -- since you can have windows-native
dlls, Paul's unix-emulation-environment-based dll's (PW), cygwin dll's,
UWin dll's -- all with (potentially) the same name.  Since windows-dll
loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
similar, you've got a problem.

It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW
LD_LIBRARY_PATH' etc.  But that probably requires that you abandon dll's
altogether, create your own 'so' file format, write an ld.so (ld.dll?)
that will load .so's 'just like unix (tm)'.  And, for this to work
cleanly, such a beast would have to be written for ALL the major unix
emulation environments.  However, we're just concerned with cygwin,
here.  (I can't take credit for this idea; both Tor Lillqvist and Chris
Faylor have on occaision mentioned something similar)

While not abandoning the preceding idea, it IS a lot of work (and there
are a lot of implementation details to work out).  Although, it *will*
fix point (1) *and* point (2) above.  

Now, you can (mostly) fix point (2: runtime loading) by the simple
expedient of insuring that all dll's and exe's go into the same
directory. Ugly, but much easier that the above semi-proposal.  An
alternative solution to point (2) is to choose a unique prefix for dll's
built on each platform -- e.g. Paul's suggestion of 'cygfoo.dll' for
cygwin and 'pwfoo.dll' for his PW environment.  NOTE: you only need to
munge the prefix of the dll itself; the import lib and/or static lib can
still be 'libfoo.dll.a' or 'libfoo.a' -- because at
compiletime/linktime, we *control* the library search path and are not
limited by the global windows executable path.

You can (mostly) fix point (1: compiletime version) by careful naming
and use of import libs + careful naming and use of dll's.

For instance:

  libpng.dll.a  --> libpng3.dll.a  
                ^^
              symlink

  libpng30.dll.a  (most recent API, corresponds to png-2.0.x)
    embeds the name "libpng3.dll"
  libpng20.dll.a  (older API, corresponds to png-1.0.x)
    embeds the name "libpng2.dll"

Programs linked against '-lpng' will be dependent at runtime on
libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before
version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a)
will be dependent at runtime on libpng2.dll

Now, suppose that the png folks release a newer version, say png-2.1.x
that exposes some additional features, but is backwards compatible with
png-2.0.x.  Great.  You build it, but create:

  libpng31.dll.a (embeds the name libpng31.dll.a)
  libpng.dll.a -> libpng31.dll.a
  libpng3.dll (replaces the old version (*))

Now, /usr/lib contains:
  libpng.dll.a -> libpng31.dll.a
  libpng31.dll.a
  libpng30.dll.a
  libpng20.dll.a
and /usr/bin contains:
  libpng3.dll
  libpng2.dll

(*) you can't play simlink games with the dll's themselves, because the
windows loader doesn't grok cygwin's symlinks.  You *can* play simlink
games, as I've shown here, with the import libs, because the cygwin ld
and cygwin gcc do grok symlinks.

This scheme will work without the help of libtool (e.g. you can still
build & link dependent packages without being *forced* to use libtool)
but it's similar enough to the 'unix way' that libtool should be able to
handle it.

> 
> Libtool doesn't version dll's on Windows correctly right now, it uses
> the linux versioning scheme to calculate the numbers.  It should
> probably name them after the oldest ``interface'' (see the document
> quoted above) that the library fully supports.  That is, if you build
> a dll using libtool's --version 5:4:3, you would get library2.dll
                                                       ^^^^^^^^^^^^
                   I think you mean library3.dll (supports v5, v4, & v3)

> (this version is at interface 5, but fully supports the last 3
> interfaces).  This gives the windows loader the best chance of finding
> the newest binary compatible dll.

In my scheme, --version 5:4:3 will give you library3.dll (assuming my
correction above is right), but you'd also get:

 library.dll.a --> library5.dll.a
 library5.dll.a (embeds the name library2.dll)

And these are still hanging around from previous builds
 library4.dll.a (embeds the name library2.dll)
 library3.dll.a (embeds the name library2.dll)
 library2.dll.a (embeds the name library1.dll)
 library1.dll

> 
> Unfortunately Windows makes no distinction between the application
> search path and the library search path, so the scheme I propose is
> still flawed =(O|  You might have a newer bugfixed binary compatible
> version of the dll you need, but if it is further down the application
> search path than the buggy version you originally linked with, you get
> the broken version.  Nice one Bill...

Yeah, but you're still assuming that the link lib and the runtime lib
are the same file.

> 
> Maybe Cygwin should put all of it's libtool built libraries (or any
> others that are correctly versioned w.r.t the runtime loader) into a
> single directory that is near the front of the default path.  /usr/lib
> seems like a good place.

That's part of my 'easy' solution above.  It may fix the cygwin problem,
but the requirement is not nice to native apps or other unix-on-win
emulations that the user may have.

Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
cygwin exe and EVERY cygwin dll are piled into the same dir.

I *think* the combination of implib/dll versioning described above, plus
(sigh) unique prefixes for different platforms -- e.g. 'cygfoo.dll' --
will solve most of the problems brought up w.r.t compiletime/linktime
versioning, and runtime loading.  Without interfering too much with
native apps or other unix-emul packages.  So what do you lose?

-1) Can't link directly to a dll; you must use an import lib.  (why? #1,
ld only hunts for libfoo.dll & foo.dll, not cygfoo.dll. #2, if you link
directly to dll's without using import libs, you lose the clean
separation between 'runtime links' and 'development links' -- see
http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html .  I
know, there aren't really any 'runtime' symlinks, but at least you can
separate the major so-names...)

-2) It's a helluva lot of work to change everything on a platform (say,
cygwin) so that all dll's start with 'cyg' instead of 'lib'

-3) It mostly solves a lot of the issues, but not completely. Not
ideally. Not perfectly.

-4) Still requires significant changes to libtool to handle dll's and
importlibs.

What do you gain?

+1) mostly solves the problem
+2) you can still link dynamically or statically, without the use of
libtool if you so choose
+3) you don't have to develop an ld.so 'smart' runtime loader

Is +3) a bigger win than work involved in -2) ?
Will Chris, DJ, Corinna, et. al. even go for -2) ?

Developing an ld.so runtime loader requires far fewer changes to
libtool, and since you *can* link directly to dll's (*) it'll work 'just
like unix (tm). But developing ld.so will be a tough job.

(*) DJ has pushed a feature into ld that generates a 'virtual' import
lib on-the-fly if you put a dll in the link line.

--Chuck

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Gary V. Vaughan]

On Sat, Sep 02, 2000 at 02:36:03PM -0400, Charles S. Wilson wrote:
> "Gary V. Vaughan" wrote:
> > 
> > Charles S. Wilson wrote:
> > >
> > > There is *something* in the windows system that gets notified that
> > > myapp.exe depends on mydll.dll whenever you execute myapp.exe.  This
> > > *something* searches the file system according to the search path
> > > described earlier in this thread, loads the dll into the executable
> > > process's memeory space (rebasing the memory location if necessary), and
> > > fixes up all the internal pointers to match the in-process virtual
> > > memory location.
> > >
> > > Isn't that considered a dynamic linker? (Whether you call that
> > > *something* a dynamic linker or not is really immaterial.  The
> > > *something* is a runtime loader, and that's what the reference above is
> > > discussing)
> > 
> > Nope.  Tor is correct.  The libtool versioning system assumes that the
> > runtime loader is smart enough to choose the most recent compatible
> > version of each dll that an application was linked with.  Many of the
> > operating systems that libtool supports have different rules for how
> > to name these versions so that the runtime loader can do it's stuff.
> > Libtool maps the unified version number scheme it exposes to the user
> > onto the versioning rules for the host platform.  That is why it is
> > okay to have libc5 and libc6 in the same directory on your Linux box.
> > Infact I could have several incompatible versions of libc6 in my lib
> > directory, and the runtime loader would choose the newest one that is
> > binary compatible with the version that the application was originally
> > linked with.
> 
> Hmmm....you can do this sort of thing -- in a limited way, of course --
> with appropriate naming of the dll and importlib.  Recall that import
> libs contain the hardcoded name of the dll for which they were built.
> 
> Also, there are two separate issues being discussed here: (1) how to
> (compile-time) link against the 'right' version of a library, and (2)
> how to insure that the 'right' dll is loaded at run-time.

Nah.  I'm talking about (2) only.  I *am* assuming that at link time
the only version of a library you can link with is the one that
corresponds with the header files you have installed.

> In the first
> case, 'right' just means the correct version that supports the necessary
> interface; in the second case, 'right' means the correct version
> compiled for the right environment -- since you can have windows-native
> dlls, Paul's unix-emulation-environment-based dll's (PW), cygwin dll's,
> UWin dll's -- all with (potentially) the same name.

Okay.  I probably wasn't thinking too hard about that...

> Since windows-dll
> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> similar, you've got a problem.

Most definitely.

> It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW
> LD_LIBRARY_PATH' etc.  But that probably requires that you abandon dll's
> altogether, create your own 'so' file format, write an ld.so (ld.dll?)
> that will load .so's 'just like unix (tm)'.  And, for this to work
> cleanly, such a beast would have to be written for ALL the major unix
> emulation environments.  However, we're just concerned with cygwin,
> here.  (I can't take credit for this idea; both Tor Lillqvist and Chris
> Faylor have on occaision mentioned something similar)

In an ideal world.  I'd be surprised if anyone is keen enough to
actually write it though.  Far more likely that we can find the time
to make incremental improvements and adopt some conventions that make
things work a bit better...

> While not abandoning the preceding idea, it IS a lot of work (and there
> are a lot of implementation details to work out).  Although, it *will*
> fix point (1) *and* point (2) above.  
> 
> Now, you can (mostly) fix point (2: runtime loading) by the simple
> expedient of insuring that all dll's and exe's go into the same
> directory. Ugly, but much easier that the above semi-proposal.  An
> alternative solution to point (2) is to choose a unique prefix for dll's
> built on each platform -- e.g. Paul's suggestion of 'cygfoo.dll' for
> cygwin and 'pwfoo.dll' for his PW environment.  NOTE: you only need to
> munge the prefix of the dll itself; the import lib and/or static lib can
> still be 'libfoo.dll.a' or 'libfoo.a' -- because at
> compiletime/linktime, we *control* the library search path and are not
> limited by the global windows executable path.

I with you all the way so far...

> You can (mostly) fix point (1: compiletime version) by careful naming
> and use of import libs + careful naming and use of dll's.
> 
> For instance:
> 
>   libpng.dll.a  --> libpng3.dll.a  
>                 ^^
>               symlink
> 
>   libpng30.dll.a  (most recent API, corresponds to png-2.0.x)
>     embeds the name "libpng3.dll"
>   libpng20.dll.a  (older API, corresponds to png-1.0.x)
>     embeds the name "libpng2.dll"
> 
> Programs linked against '-lpng' will be dependent at runtime on
> libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before
> version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a)
> will be dependent at runtime on libpng2.dll

Why bother with the symlinks?  You can't link against -lpng2 unless
you have matching headers, and presumably you upgraded those when you
installed libpng3.dll.

My proposal was to start with this:

    libpng.dll.a embeds libpng2.dll
    
    and we keep libpng1.dll around for the applications that were
    linked against interface 1.
    
when we install png-2.0, which implements a new interface that is not
compatible with libpng2.dll, we install:

    a replacement libpng.dll.a that embeds libpng3.dll
    libpng3.dll
    
    and we keep libpng2.dll around for the applications that were
    linked against interface 2.

    and we keep libpng1.dll around for the applications that were
    linked against interface 1.

> Now, suppose that the png folks release a newer version, say png-2.1.x
> that exposes some additional features, but is backwards compatible with
> png-2.0.x.  Great.  You build it, but create:
> 
>   libpng31.dll.a (embeds the name libpng31.dll.a)
>   libpng.dll.a -> libpng31.dll.a
>   libpng3.dll (replaces the old version (*))

I don't think we need anything more than

    a replacement libpng3.dll
    
now applications that were linked against the libpng3.dll from png-2.0
will pick up the bugfixes from png-2.1, but new application can be
written for the header files installed with png-2.1 and take advantage
of the new features.


> Now, /usr/lib contains:
>   libpng.dll.a -> libpng31.dll.a
>   libpng31.dll.a
>   libpng30.dll.a
>   libpng20.dll.a
> and /usr/bin contains:
>   libpng3.dll
>   libpng2.dll
> 
> (*) you can't play simlink games with the dll's themselves, because the
> windows loader doesn't grok cygwin's symlinks.  You *can* play simlink
> games, as I've shown here, with the import libs, because the cygwin ld
> and cygwin gcc do grok symlinks.
> 
> This scheme will work without the help of libtool (e.g. you can still
> build & link dependent packages without being *forced* to use libtool)
> but it's similar enough to the 'unix way' that libtool should be able to
> handle it.

Except that I think you have an extra level of indirection that we can
safely do away with.  Otherwise we are still in violent agreement.

> > Libtool doesn't version dll's on Windows correctly right now, it uses
> > the linux versioning scheme to calculate the numbers.  It should
> > probably name them after the oldest ``interface'' (see the document
> > quoted above) that the library fully supports.  That is, if you build
> > a dll using libtool's --version 5:4:3, you would get library2.dll
>                                                        ^^^^^^^^^^^^
>                    I think you mean library3.dll (supports v5, v4, & v3)

Nope.  5:4:3 is revision 4 of the implementation of interface 5, which
is backwards compatible with the 3 previous interface definitions
(i.e. it is safe for applications linked against interfaces 5, 4, 3
and 2 to load the 5:4:3 dll at runtime).   Libtool translates the
5:4:3 into a system specific version number for the soname to help the
runtime loadee choose the best available library at runtime.  As I
said before, currently this mapping is wrong on Windows, and I think
the correct mapping is to always use the oldest supported interface
number -- in this case library2.dll -- when generating the soname.
This is explained fully in the version node of the libtool manual link
that was quoted earlier in the thread. 

> > (this version is at interface 5, but fully supports the last 3
> > interfaces).  This gives the windows loader the best chance of finding
> > the newest binary compatible dll.
> 
> In my scheme, --version 5:4:3 will give you library3.dll (assuming my
> correction above is right), but you'd also get:
> 
>  library.dll.a --> library5.dll.a
>  library5.dll.a (embeds the name library2.dll)
> 
> And these are still hanging around from previous builds
>  library4.dll.a (embeds the name library2.dll)
>  library3.dll.a (embeds the name library2.dll)
>  library2.dll.a (embeds the name library1.dll)
>  library1.dll

Okay we're diverging a little here.  I think that all you need is
library.dll.a, which always embeds the name of the dll that matches
the header files you have installed right now.  The point about
library1.dll and library2.dll is spot on though.

> > Unfortunately Windows makes no distinction between the application
> > search path and the library search path, so the scheme I propose is
> > still flawed =(O|  You might have a newer bugfixed binary compatible
> > version of the dll you need, but if it is further down the application
> > search path than the buggy version you originally linked with, you get
> > the broken version.  Nice one Bill...
> 
> Yeah, but you're still assuming that the link lib and the runtime lib
> are the same file.

Nope.  If we maintain the versions of library.dll according to either
of our schemes (which are broadly the same), it all breaks down if
some bozo installs a library2.dll in a location higher up our
*application* search path that the directory we are using, since our
applications will load their dll instead.  Maybe ours is the
library5.dll.a version with 2 releases worth of bugfixes and
enhancements over their library3.dll.a version they installed.

> > Maybe Cygwin should put all of it's libtool built libraries (or any
> > others that are correctly versioned w.r.t the runtime loader) into a
> > single directory that is near the front of the default path.  /usr/lib
> > seems like a good place.
> 
> That's part of my 'easy' solution above.  It may fix the cygwin problem,
> but the requirement is not nice to native apps or other unix-on-win
> emulations that the user may have.
> 
> Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> cygwin exe and EVERY cygwin dll are piled into the same dir.

Can't we assume that the native dll's we rely on are outside cygwin's
control and can be relied upon to be managed by the operating system
(I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
libraries (such as Pauls pw dlls) will not be installed into the
cygwin binary search path?  In which case I think it is okay to
install all cygwin dlls and import libs to /usr/lib, making sure that
cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
$PATH.  Does cygwin ld use -rpath yet?  If so we could encode
/usr/lib into each application as the first place to *always* look
when searching for a dll. (I guess I am asking whether the Windows
runtime loader will honor whatever rpath directory cygwin ld may
encode into an application -- as happens with all of the Unix ports of
libtool).

> I *think* the combination of implib/dll versioning described above, plus
> (sigh) unique prefixes for different platforms -- e.g. 'cygfoo.dll' --
> will solve most of the problems brought up w.r.t compiletime/linktime
> versioning, and runtime loading.  Without interfering too much with
> native apps or other unix-emul packages.  So what do you lose?
> 
> -1) Can't link directly to a dll; you must use an import lib.  (why? #1,
> ld only hunts for libfoo.dll & foo.dll, not cygfoo.dll. #2, if you link
> directly to dll's without using import libs, you lose the clean
> separation between 'runtime links' and 'development links' -- see
> http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html .  I
> know, there aren't really any 'runtime' symlinks, but at least you can
> separate the major so-names...)

The cygfoo point is well taken.  I'm not sure I would accept that
patch anymore...  infact I think that it is not a necessary part of
this proposal (either of our proposals infact) if we have some way to
control the runtime dll search path (by always putting /usr/lib first
in the PATH for example).

> -2) It's a helluva lot of work to change everything on a platform (say,
> cygwin) so that all dll's start with 'cyg' instead of 'lib'

This may be a non issue if you agree with my last paragraph.

> -3) It mostly solves a lot of the issues, but not completely. Not
> ideally. Not perfectly.

Hey.  This is Windows we're talking about =)O|

> -4) Still requires significant changes to libtool to handle dll's and
> importlibs.

Not that significant.  And this is all stuff that is on libtool's TODO
list anyway.  It will get done eventually, just as soon as we can nail
down a proposal that everyone (well most of us at least) likes.

> What do you gain?
> 
> +1) mostly solves the problem
> +2) you can still link dynamically or statically, without the use of
> libtool if you so choose

That is important, and I am prepared to accept a patch (nay, write a
patch in the fullness of time) to have libtool deal with import libs
properly.

> +3) you don't have to develop an ld.so 'smart' runtime loader
> 
> Is +3) a bigger win than work involved in -2) ?

I think so.  Unless someone steps up to the plate and offers to
implement an ld.so-a-like, I am prepared to work on having libtool do
the right thing as far as possible.

> Will Chris, DJ, Corinna, et. al. even go for -2) ?

Guys?  Stop me now if you violently disagree with libtool taking this
direction =)O|

> Developing an ld.so runtime loader requires far fewer changes to
> libtool, and since you *can* link directly to dll's (*) it'll work 'just
> like unix (tm). But developing ld.so will be a tough job.
> 
> (*) DJ has pushed a feature into ld that generates a 'virtual' import
> lib on-the-fly if you put a dll in the link line.

Yup. I picked his brains while he was doing it, and wrote something
similar for libtool.  By default libtool always searches for a dll to
link against and generates the implib on the fly if a suitable one is
found.

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> Since windows-dll
>> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> similar, you've got a problem.
>
>Most definitely.

It is *not* strictly based on the executable path.  It first searches
the current directory, then searches the directory containing the executable.
Most Windows packages rely on this and place the DLL with the executable.
That should solve the problem of finding the "wrong" dll.

I'm still kind of amazed by all of the furor this discussion is generating,
given that I don't think we have yet seen a single problem reported.

If this was a big deal I would have thought that there would be many many
plaintive wails in this mailing list.

If the solution to the problem is as simple as placing the DLL with the
executable then why the heck don't we just do that?  I love being as
close to UNIX as possible but if it is going to cause problems then
it makes sense not to do things that way.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Robert Collins]

I have only 1 concern with putting the .dll's in the same directory as an
application that needs them... you have to copy n instances of an updated
.dll to upgrade a library.

i.e. if you have gnome, and gtk+ is updated you have to copy the new .dll to
5-10+locations, depending on the number of applications you have...

Does anyone know exactly where the registry DLL location list goes in the
dll search order? Or does the application have to use it?

That might offer an alternative search mechanism we could place in
cygwin(and yes I'd be happy to put some time into writing it - although with
no guarantees about time-frame), without writing a brand-new run-time
loader...

Rob

----- Original Message -----
From: "Chris Faylor" <cgf@cygnus.com>
To: <cygwin@sources.redhat.com>
Cc: <gvv@techie.com>
Sent: Sunday, September 03, 2000 1:19 PM
Subject: Re: DLL naming conventions


> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
>
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the
executable.
> Most Windows packages rely on this and place the DLL with the executable.
> That should solve the problem of finding the "wrong" dll.
>
> I'm still kind of amazed by all of the furor this discussion is
generating,
> given that I don't think we have yet seen a single problem reported.
>
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
>
> If the solution to the problem is as simple as placing the DLL with the
> executable then why the heck don't we just do that?  I love being as
> close to UNIX as possible but if it is going to cause problems then
> it makes sense not to do things that way.
>
> cgf
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles Wilson]

"Gary V. Vaughan" wrote:
> >
> > Also, there are two separate issues being discussed here: (1) how to
> > (compile-time) link against the 'right' version of a library, and (2)
> > how to insure that the 'right' dll is loaded at run-time.
> 
> Nah.  I'm talking about (2) only.  I *am* assuming that at link time
> the only version of a library you can link with is the one that
> corresponds with the header files you have installed.

Okay. I was just going by the example from
http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html , quoted
here:

-------------------
> The development links become a bit more complex. The temptation is to
> place both development sets in their own subdirectories, providing:
> 
>      /usr/include/gmp1
> and
>      /usr/include/gmp2
> 
> and the development symlinks:
> 
>      libgmp1.so
> and
>      libgmp2.so
> 
> This causes problems for packages which expect to build against gmp.
> Having to edit the make file to reflect the correct include and link names
> is not a clean solution.
> 
> Thus, for gmp-2.0.2, the includes are provided in /usr/include, and the
> development link is libgmp.so. Only gmp1 need be placed in the special
> locations above.
--------------------

But, you are right. The extra linktime libaries are only necessary if
you also have the extra header files in a special directory.  Since you
have to edit the makefiles (and possible the source code) for 'package
X' that depends on the old interface (gmp1 in this example), then you
might as well specify '-lgmp1' and you don't need the symlinks.

<snip>
 
> > Since windows-dll
> > loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> > similar, you've got a problem.
> 
> Most definitely.

Chris argues against this in his other message. I'll reply to that point
in a separt message.

> 
> > It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW
> > LD_LIBRARY_PATH' etc.  But that probably requires that you abandon dll's
> > altogether, create your own 'so' file format, write an ld.so (ld.dll?)
> > that will load .so's 'just like unix (tm)'.  And, for this to work
> > cleanly, such a beast would have to be written for ALL the major unix
> > emulation environments.  However, we're just concerned with cygwin,
> > here.  (I can't take credit for this idea; both Tor Lillqvist and Chris
> > Faylor have on occaision mentioned something similar)
> 
> In an ideal world.  I'd be surprised if anyone is keen enough to
> actually write it though.  Far more likely that we can find the time
> to make incremental improvements and adopt some conventions that make
> things work a bit better...

I think the ld.so stuff is very ambitious. IMO, it's something to keep
in mind for the next major revision of cygwin -- but then, I'm not an
official spokesman.

Again, IMO, 'adopting some conventions' is the way to go right now --
just like we adopted the convention that 'libfoo.dll.a' means an import
lib.

<snip>

> > You can (mostly) fix point (1: compiletime version) by careful naming
> > and use of import libs + careful naming and use of dll's.
> >
> > For instance:
> >
> >   libpng.dll.a  --> libpng3.dll.a
> >                 ^^
> >               symlink
> >
> >   libpng30.dll.a  (most recent API, corresponds to png-2.0.x)
> >     embeds the name "libpng3.dll"
> >   libpng20.dll.a  (older API, corresponds to png-1.0.x)
> >     embeds the name "libpng2.dll"
> >
> > Programs linked against '-lpng' will be dependent at runtime on
> > libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before
> > version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a)
> > will be dependent at runtime on libpng2.dll
> 
> Why bother with the symlinks?  You can't link against -lpng2 unless
> you have matching headers, and presumably you upgraded those when you
> installed libpng3.dll.
> 
> My proposal was to start with this:
> 
>     libpng.dll.a embeds libpng2.dll
> 
>     and we keep libpng1.dll around for the applications that were
>     linked against interface 1.
> 
> when we install png-2.0, which implements a new interface that is not
> compatible with libpng2.dll, we install:
> 
>     a replacement libpng.dll.a that embeds libpng3.dll
>     libpng3.dll
> 
>     and we keep libpng2.dll around for the applications that were
>     linked against interface 2.
> 
>     and we keep libpng1.dll around for the applications that were
>     linked against interface 1.

You are (mostly) right. The symlinks are not really necessary -- but
keeping libpng20.dll.a is a good idea (assuming you also kept the 2.0.x
headers around, and put them in /usr/include/png2/.  

The symlink buys you ease of installation for the implib.  Suppose you
had 1.0.x installed, so libpng.dll.a embeds libpng2.dll.  Then, you
install 2.0.x.  First, you need to rename libpng.dll.a to libpng2.dll.a,
and then install the new implib as libpng.dll.a.  With symlinks, none of
that is necessary -- just install the new implib as libpng30.dll.a and
replace the existing symlink with one that points to the new implib.
Easy.

BUT -- you still need smarts create the appropriate /usr/include/png2/
directory, move the header files into it, and then install the new
headers into /usr/include.

Yuck yuck and double yuck. Okay, forget the symlinks -- they help with
the implibs, but nothin' helps with the header files.

The "Right Thing To Do", if you want development stuff (compile time
headers, link time import libs) for multiple incompatible versions of a
lib, is for the maintainer (the cygwin person who maintains the port of
a particular package, on sourceware -- for libpng, me) to do the
following:

 Oh, look: libpng-2.0.x is out.  That's not compatible with
libpng-1.0.x.  I need to create a new libpng-1.0.x package that installs
thusly:
  /usr/include/png2/*.h
  /usr/bin/libpng2.dll
  /usr/lib/libpng2.dll.a (libpng20.dll.a?)

Then, I can create a new libpng-2.0.x package that installs like so:
  /usr/include/*.h
  /usr/bin/libpng3.dll
  /usr/lib/libpng3.dll.a (libpng30.dll.a?)

And tell folks to install both the updated 1.0.x package and the new
2.0.x package.  Just like you see done in the linux distributions:
especially gmp1 and gmp2.

> 
> > Now, suppose that the png folks release a newer version, say png-2.1.x
> > that exposes some additional features, but is backwards compatible with
> > png-2.0.x.  Great.  You build it, but create:
> >
> >   libpng31.dll.a (embeds the name libpng31.dll.a)
> >   libpng.dll.a -> libpng31.dll.a
> >   libpng3.dll (replaces the old version (*))
> 
> I don't think we need anything more than
> 
>     a replacement libpng3.dll

Not so.  Remember, libpng-2.1.x can include additional functions that
were not included by libpng-2.0.x, as long as it includes all of the
'old' functions/vars without modification.  So, you need to update the
import lib as well as the dll, so that new packages that use the
additional functions will work.

> 
> now applications that were linked against the libpng3.dll from png-2.0
> will pick up the bugfixes from png-2.1, but new application can be
> written for the header files installed with png-2.1 and take advantage
> of the new features.

Unless you link directly against the dll (and don't use the import lib)
this new application won't link -- because the new features (additional
functions) added in the new version of the png library won't be exposed
by the old implib.

> 
> > Now, /usr/lib contains:
> >   libpng.dll.a -> libpng31.dll.a
> >   libpng31.dll.a
> >   libpng30.dll.a
> >   libpng20.dll.a
> > and /usr/bin contains:
> >   libpng3.dll
> >   libpng2.dll
> >
> > (*) you can't play simlink games with the dll's themselves, because the
> > windows loader doesn't grok cygwin's symlinks.  You *can* play simlink
> > games, as I've shown here, with the import libs, because the cygwin ld
> > and cygwin gcc do grok symlinks.
> >
> > This scheme will work without the help of libtool (e.g. you can still
> > build & link dependent packages without being *forced* to use libtool)
> > but it's similar enough to the 'unix way' that libtool should be able to
> > handle it.
> 
> Except that I think you have an extra level of indirection that we can
> safely do away with.  Otherwise we are still in violent agreement.

I agree. The symlinks are unnecessary, because of the difficulties
imposed by keeping track of the header files for the old version.  You
just need to create a new package for the old library, that relocates
and renames the implib and headers appropriately.  

> 
> > > Libtool doesn't version dll's on Windows correctly right now, it uses
> > > the linux versioning scheme to calculate the numbers.  It should
> > > probably name them after the oldest ``interface'' (see the document
> > > quoted above) that the library fully supports.  That is, if you build
> > > a dll using libtool's --version 5:4:3, you would get library2.dll
> >                                                        ^^^^^^^^^^^^
> >                    I think you mean library3.dll (supports v5, v4, & v3)
> 
> Nope.  5:4:3 is revision 4 of the implementation of interface 5, which
> is backwards compatible with the 3 previous interface definitions
> (i.e. it is safe for applications linked against interfaces 5, 4, 3
> and 2 to load the 5:4:3 dll at runtime).   Libtool translates the
> 5:4:3 into a system specific version number for the soname to help the
> runtime loadee choose the best available library at runtime.  As I
> said before, currently this mapping is wrong on Windows, and I think
> the correct mapping is to always use the oldest supported interface
> number -- in this case library2.dll -- when generating the soname.
> This is explained fully in the version node of the libtool manual link
> that was quoted earlier in the thread.

Doh!  0-based numbering. Not 1-based numbering.

> 
> > > (this version is at interface 5, but fully supports the last 3
> > > interfaces).  This gives the windows loader the best chance of finding
> > > the newest binary compatible dll.
> >
> > In my scheme, --version 5:4:3 will give you library3.dll (assuming my
> > correction above is right), but you'd also get:
> >
> >  library.dll.a --> library5.dll.a
> >  library5.dll.a (embeds the name library2.dll)
> >
> > And these are still hanging around from previous builds
> >  library4.dll.a (embeds the name library2.dll)
> >  library3.dll.a (embeds the name library2.dll)
> >  library2.dll.a (embeds the name library1.dll)
> >  library1.dll
> 
> Okay we're diverging a little here.  I think that all you need is
> library.dll.a, which always embeds the name of the dll that matches
> the header files you have installed right now.  The point about
> library1.dll and library2.dll is spot on though.

You are correct, unless one also installs the appropriate header files
in 
  /usr/include/library4/
  /usr/include/library3/
  /usr/include/library2/

> 
> > > Unfortunately Windows makes no distinction between the application
> > > search path and the library search path, so the scheme I propose is
> > > still flawed =(O|  You might have a newer bugfixed binary compatible
> > > version of the dll you need, but if it is further down the application
> > > search path than the buggy version you originally linked with, you get
> > > the broken version.  Nice one Bill...
> >
> > Yeah, but you're still assuming that the link lib and the runtime lib
> > are the same file.
> 
> Nope.  If we maintain the versions of library.dll according to either
> of our schemes (which are broadly the same), it all breaks down if
> some bozo installs a library2.dll in a location higher up our
> *application* search path that the directory we are using, since our
> applications will load their dll instead.  Maybe ours is the
> library5.dll.a version with 2 releases worth of bugfixes and
> enhancements over their library3.dll.a version they installed.

This is true.

> 
> > > Maybe Cygwin should put all of it's libtool built libraries (or any
> > > others that are correctly versioned w.r.t the runtime loader) into a
> > > single directory that is near the front of the default path.  /usr/lib
> > > seems like a good place.
> >
> > That's part of my 'easy' solution above.  It may fix the cygwin problem,
> > but the requirement is not nice to native apps or other unix-on-win
> > emulations that the user may have.
> >
> > Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> > cygwin exe and EVERY cygwin dll are piled into the same dir.
> 
> Can't we assume that the native dll's we rely on are outside cygwin's
> control and can be relied upon to be managed by the operating system
> (I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
> libraries (such as Pauls pw dlls) will not be installed into the
> cygwin binary search path?  In which case I think it is okay to
> install all cygwin dlls and import libs to /usr/lib, making sure that
> cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
> $PATH.  

this works for the 'sandbox user' -- Michael Ring's 'user 1' in this
message:
   http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html

It doesn't work for Michael's 'user 2' -- the guy who normally runs in
cmd.exe/command.com, but relies on cygwin commands every once in a
while.  He doesn't use bash, but likes the cygwin-perl or grep every
once and a while.  User 2 will have the cygwin directories somewhere in
her path -- but not necessarily first.

> Does cygwin ld use -rpath yet?  

I don't think so.  -rpath is something that ld.so uses; Windows doesn't
have ld.so. Windows *always* loads dll's according to the following
search order:
   current directory
   app's load directory
   global executable search path

The only two exceptions I know of are:

  1) In Win2K, if there is a file called 'app.exe.local' in the same
directory as app.exe, then all dll's will be loaded from the app's load
directory -- even if explicitly dlopened() with an absolute path that
points elsewhere.  the .local. may also override the 'current directory'
part of the search order listed above, but I'm not sure.

  2) You can put something called 'AppPath' in the registry, which will
influence the directories that are searched. I don't know where in the
list above that the directories listed in the 'AppPath' key are
inserted.

> If so we could encode
> /usr/lib into each application as the first place to *always* look
> when searching for a dll. (I guess I am asking whether the Windows
> runtime loader will honor whatever rpath directory cygwin ld may
> encode into an application -- as happens with all of the Unix ports of
> libtool).

Nope. Don't think so.  That's why the suggestion to implement an
ld.so-like loader specifically for cygwin is an attractive, but
extremely difficult, option.

> 
> > I *think* the combination of implib/dll versioning described above, plus
> > (sigh) unique prefixes for different platforms -- e.g. 'cygfoo.dll' --
> > will solve most of the problems brought up w.r.t compiletime/linktime
> > versioning, and runtime loading.  Without interfering too much with
> > native apps or other unix-emul packages.  So what do you lose?
> >
> > -1) Can't link directly to a dll; you must use an import lib.  (why? #1,
> > ld only hunts for libfoo.dll & foo.dll, not cygfoo.dll. #2, if you link
> > directly to dll's without using import libs, you lose the clean
> > separation between 'runtime links' and 'development links' -- see
> > http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html .  I
> > know, there aren't really any 'runtime' symlinks, but at least you can
> > separate the major so-names...)
> 
> The cygfoo point is well taken.  I'm not sure I would accept that
> patch anymore...  infact I think that it is not a necessary part of
> this proposal (either of our proposals infact) if we have some way to
> control the runtime dll search path (by always putting /usr/lib first
> in the PATH for example).

Again, works for Michael's 'user 1', but not for 'user 2'.  And there
are a lot of 'user 2's out there.

> 
> > -2) It's a helluva lot of work to change everything on a platform (say,
> > cygwin) so that all dll's start with 'cyg' instead of 'lib'
> 
> This may be a non issue if you agree with my last paragraph.
> 
> > -3) It mostly solves a lot of the issues, but not completely. Not
> > ideally. Not perfectly.
> 
> Hey.  This is Windows we're talking about =)O|
> 
> > -4) Still requires significant changes to libtool to handle dll's and
> > importlibs.
> 
> Not that significant.  And this is all stuff that is on libtool's TODO
> list anyway.  It will get done eventually, just as soon as we can nail
> down a proposal that everyone (well most of us at least) likes.
> 
> > What do you gain?
> >
> > +1) mostly solves the problem
> > +2) you can still link dynamically or statically, without the use of
> > libtool if you so choose
> 
> That is important, and I am prepared to accept a patch (nay, write a
> patch in the fullness of time) to have libtool deal with import libs
> properly.
> 
> > +3) you don't have to develop an ld.so 'smart' runtime loader
> >
> > Is +3) a bigger win than work involved in -2) ?
> 
> I think so.  Unless someone steps up to the plate and offers to
> implement an ld.so-a-like, I am prepared to work on having libtool do
> the right thing as far as possible.

I think libtool should do the right thing anyway; even if an ld.so-clone
is proposed and work begins, it'll be a LONNNGGG time before a beast
like that is ready for prime time.

What was the right thing, again?  :-)

> 
> > Will Chris, DJ, Corinna, et. al. even go for -2) ?
> 
> Guys?  Stop me now if you violently disagree with libtool taking this
> direction =)O|
> 
> > Developing an ld.so runtime loader requires far fewer changes to
> > libtool, and since you *can* link directly to dll's (*) it'll work 'just
> > like unix (tm). But developing ld.so will be a tough job.
> >
> > (*) DJ has pushed a feature into ld that generates a 'virtual' import
> > lib on-the-fly if you put a dll in the link line.
> 
> Yup. I picked his brains while he was doing it, and wrote something
> similar for libtool.  By default libtool always searches for a dll to
> link against and generates the implib on the fly if a suitable one is
> found.

There are occaisions where you want to link to an import lib in
preference to a dll -- for instance, libcygwin.a is an import lib, but
contains initializer code and actual function implementations for some
functions that are not included in the dll itself.  If you attempt to
link directly to cygwin1.dll, the link fails because those things are
missing from the virtual on-the-fly implib.

These cases are rare.

It's possible that we can do away completely with import libs for most
libraries: based on my tests, all of the following four scenarios work:

libfoo.dll & libfoo.dll.a compiled with __declspec(dllexport)
decorations on all functions and data
use-libfoo.o compiled with __declspec(dllimport) decorations on all
functions and data

link use-libfoo.o to libpfoo.dll.a
  -- generates a working executable

link use-libfoo.o to libfoo.dll
  -- generates a working executable

libfoo.dll & libfoo.dll.a compiled with __declspec(dllexport)
decorations *ONLY* on data, not functions
use-libfoo.o compiled with __declspec(dllimport) decorations *ONLY* on
data, not functions

link use-libfoo.o to libpfoo.dll.a
  -- generates a working executable

link use-libfoo.o to libfoo.dll
  -- generates a working executable

So, it seems that there is no case in which the import lib gives you
better behavior than the dll itself.

But where do you put the dll?  It has to go into the executable PATH so
that the windows loader can find it.  Do you copy it into /usr/lib, so
that the default ld search path will find it?  Do you add /usr/bin to
the linktime library search path (-L/usr/bin)?  Perhaps a symlink in
/usr/lib, pointing to /usr/bin/libfoo.dll is all you need. 

However!!! Ld uses the following library name search order when hunting
for -lfoo:

  libfoo.dll.a
  foo.dll.a
  libfoo.a  <<<< NOTE!!
  libfoo.dll
  foo.dll

So, if both the static lib (libfoo.a) and the symlink/copy of the dll
(libfoo.dll) exist in /usr/lib, the link will grab the static lib in
preference to linking directly to the dll.  (this was a necessary
compromise for backwards compatibility; if libfoo.dll can override
libfoo.a, many things break. Don't go there).  Therefore, in order for
dynamic linking to take precedence over static linking, you have to have
an import lib in /usr/lib, not the dll.  Naturally, since libtool is
smart, it could explicitly link the dll in preference to the static lib
by listing the actual pathname of the library on the link line, instead
of relying on '-lfoo', but I thought we're trying to come up with a
solution that allows both libtool-ization and normal, unassisted
compiles.

Therefore:
  /usr/lib/libfoo.dll.a
  /usr/lib/libfoo.a
  /usr/bin/libfoo.dll  (maybe libfoo3.dll, whatever)

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Charles Wilson]

Chris Faylor wrote:
> 
> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
> 
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the executable.
> Most Windows packages rely on this and place the DLL with the executable.
> That should solve the problem of finding the "wrong" dll.

Again, ONLY if ALL cygwin exec's go into /usr/bin, along with ALL cygwin
dlls.  But what of the locally-compiled rxvt, that depends on (say) the
libXpm.dll, where libXpm.dll is part of official package
'libXpm-3.4k-2.tar.gz' in /cygwin/contrib?

Poor little rxvt.exe goes into /usr/local/bin, and will have to rely on
the good offices of Windows to locate libXpm.dll in the search path. 

Or, what of perl.exe, which depends on:
  libdb.dll
  libgdbm.dll
  libz.dll (actually, module Compress:Zlib)
which are all part of the official distro, so they live in /usr/bin. 
But, perl is not official -- it lives in /usr/local/bin.  To insure that
the 'right' libz.dll gets loaded (and I've got two on my machine -- one
cygwin, one native), I have to insure that D:\cygwin\usr\bin precedes
D:\Utils in the global path.   

That's okay, when I run cygwin in a sandbox (Michael's 'User 1') which
is my normal mode of operation.  However, User 2, who only occaisionally
calls cygwin exe's from a normal command prompt (no bash, so can't set
PATH specially for Cygwin in his .bashrc) -- he might have D:\Utils
precede D:\cygwin\usr\bin.

The odds of this occurring are, admittedly, rather low.  If the goal is
to pre-emtively prevent these confusing failures, in the hopes of
lightening the support load on the cygwin mailing list -- we've already
failed! :-) We've already spent far more time discussing this
hypothetical problem that it would take to tell one hundred newbies:
"Put /usr/bin in the front of your path".

> 
> I'm still kind of amazed by all of the furor this discussion is generating,
> given that I don't think we have yet seen a single problem reported.

Two issues have been intermingled -- (1) the 'cyg' prefix/runtime
loading "problem", and (2) the library versioning problem.  Granted, (1)
is very low probability -- see my arguments below.  (2) has not yet bit
us, because most contrib libraries have been dll-ized by me, and each
successive version of the dlls have been interface-compatible, so no
explicit versioning has been necessary. It will become necessary
eventually -- might as well discuss it now.

So, two fairly controversial topics have been co-mingled -- and
sometimes confused with each other -- so we've got 'furor'.

I did observe the dll-runtime loading problem, when I built a native
XEmacs that depended on native libz, libpng, and libtiff dll's.  My path
had /usr/bin first, so I got the cygwin libz.dll etc at runtime, and
XEmacs failed.

There were two possible fixed -- AND NEITHER ONE required cygwin
changes: relink my native XEmacs statically, or copy the native dll's
into D:\Program Files\XEmacs\xemacs-21.2.25\i386-pc-win32\  where the
xemacs.exe was.

> 
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
> 

You are correct, as usual, Chris. This is a low-probability error --
UNLESS one has multiple unix-on-windows emulators installed.  Like Paul
Sokolovsky, who apparently has both cygwin and PW.

I dunno if it's worth this much effort and discussion to fix a problem
that happens so rarely, and is fixable by less intrusive means:  
  when operating in PW mode, set your PATH so that the PW /bin,/usr/bin
is first
  when operating in Cygwin mode, set your PATH so that the cygwin
/bin,/usr/bin is first.

> If the solution to the problem is as simple as placing the DLL with the
> executable then why the heck don't we just do that? 

Won't fix the problem for exe's that aren't part of the official
install, but you can work around that by requiring that /bin,/usr/bin be
in the front of the path (prior to 'outside' dirs). Even this, though,
will not fix the problem for 'modeless' users (Michael's 'user 2') --
because modeless users don't want /usr/bin in the front.

However, no modeless users (except for Paul) have complained.  Perhaps
Paul should become modal. :-)

> I love being as
> close to UNIX as possible but if it is going to cause problems then
> it makes sense not to do things that way.

Yep -- so libtool and dll versioning issues should be addressed.  But it
appears that the 'modal' PATH requirement is the least intrusive method
of fixing the platform-specific dll confusion (e.g. native vs. cygwin
vs. UWin vs. PW dll's, all with the same name).

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Gary V. Vaughan]

On Sun, Sep 03, 2000 at 01:34:23AM -0400, Charles Wilson wrote:
> "Gary V. Vaughan" wrote:
> 
> > > Now, suppose that the png folks release a newer version, say png-2.1.x
> > > that exposes some additional features, but is backwards compatible with
> > > png-2.0.x.  Great.  You build it, but create:
> > >
> > >   libpng31.dll.a (embeds the name libpng31.dll.a)
> > >   libpng.dll.a -> libpng31.dll.a
> > >   libpng3.dll (replaces the old version (*))
> > 
> > I don't think we need anything more than
> > 
> >     a replacement libpng3.dll
> 
> Not so.  Remember, libpng-2.1.x can include additional functions that
> were not included by libpng-2.0.x, as long as it includes all of the
> 'old' functions/vars without modification.  So, you need to update the
> import lib as well as the dll, so that new packages that use the
> additional functions will work.

Oops.  I hadn't thought of that.  Good point.

> > Otherwise we are still in violent agreement.
> 
> I agree.

=)O|

> > > > Maybe Cygwin should put all of it's libtool built libraries (or any
> > > > others that are correctly versioned w.r.t the runtime loader) into a
> > > > single directory that is near the front of the default path.  /usr/lib
> > > > seems like a good place.
> > >
> > > That's part of my 'easy' solution above.  It may fix the cygwin problem,
> > > but the requirement is not nice to native apps or other unix-on-win
> > > emulations that the user may have.
> > >
> > > Relying on 'get dll's from same dir as .exe' works -- but only if EVERY
> > > cygwin exe and EVERY cygwin dll are piled into the same dir.
> > 
> > Can't we assume that the native dll's we rely on are outside cygwin's
> > control and can be relied upon to be managed by the operating system
> > (I'm thinking of stuff in the SYSTEM directory), and that non-cygwin
> > libraries (such as Pauls pw dlls) will not be installed into the
> > cygwin binary search path?  In which case I think it is okay to
> > install all cygwin dlls and import libs to /usr/lib, making sure that
> > cygwin.bat (or any other cygwin startup methods) put /usr/lib first in
> > $PATH.  
> 
> this works for the 'sandbox user' -- Michael Ring's 'user 1' in this
> message:
>    http://sources.redhat.com/ml/cygwin/2000-08/msg01241.html
> 
> It doesn't work for Michael's 'user 2' -- the guy who normally runs in
> cmd.exe/command.com, but relies on cygwin commands every once in a
> while.  He doesn't use bash, but likes the cygwin-perl or grep every
> once and a while.  User 2 will have the cygwin directories somewhere in
> her path -- but not necessarily first.

We could tell these people to put C:/cygwin/usr/bin at the front of
their PATH...

> > Does cygwin ld use -rpath yet?  
> 
> I don't think so.  -rpath is something that ld.so uses; Windows doesn't
> have ld.so. Windows *always* loads dll's according to the following
> search order:
>    current directory
>    app's load directory
>    global executable search path
> 
> The only two exceptions I know of are:
> 
>   1) In Win2K, if there is a file called 'app.exe.local' in the same
> directory as app.exe, then all dll's will be loaded from the app's load
> directory -- even if explicitly dlopened() with an absolute path that
> points elsewhere.  the .local. may also override the 'current directory'
> part of the search order listed above, but I'm not sure.

Holy cr@p! What happened to simplicity?  If Bill has decided that he
can't understand how to write a decent shared library system, and
want's to relegate dll's to LoadLibrary() objects, why doesn't he just
say so?  Wouldn't it be easier to statically link a Win2k program that
twiddle about with all this .local mess?

>   2) You can put something called 'AppPath' in the registry, which will
> influence the directories that are searched. I don't know where in the
> list above that the directories listed in the 'AppPath' key are
> inserted.

This sounds promising.  I'll see if I can find any details on it.

> > I am prepared to work on having libtool do the right thing as far
> > as possible. 
> 
> What was the right thing, again?  :-)

Based on our conversation so far:

  * When building a libtool (.la) library, create libfoo.la,
    libfoo<iface>.dll, libfoo.dll.a and libfoo.a, where:
      - <iface> is the earliest fully supported interface number
      - libfoo.dll.a is the import library for libfoo<iface>.dll
      
  * When installing a libtool (.la) library:
      - libfoo.la goes to $prefix/lib
      - libfoo<iface>.dll goes to $prefix/bin
      - libfoo.dll.a goes to $prefix/lib
      - libfoo.a goes to $prefix/lib
      
  * When linking against libfoo.la
      - use libfoo.dll.a unless -static or -all-static 
      - otherwise use libfoo.a

  * When linking against -lfoo
      - if libfoo.la is found, behave as above
      - else let ld (or gcc) do its thing

Which is especially cool, because I don't think I need to worry about
dealing with direct linkage to dlls (I can just punt and let gcc/ld do
the hard work) which removes a whole pile of spaghetti where I had to
cope with compiling the impgen code correctly in cross compilation
environments!

> > By default libtool always searches for a dll to link against and
> > generates the implib on the fly if a suitable one is found.

This won't be necessary under the new scheme =)O|

> There are occaisions where you want to link to an import lib in
> preference to a dll -- for instance, libcygwin.a is an import lib, but
> contains initializer code and actual function implementations for some
> functions that are not included in the dll itself.  If you attempt to
> link directly to cygwin1.dll, the link fails because those things are
> missing from the virtual on-the-fly implib.

I didn't know about that.  Thanks.

> But where do you put the dll?  It has to go into the executable PATH so
> that the windows loader can find it.  Do you copy it into /usr/lib, so
> that the default ld search path will find it?  Do you add /usr/bin to
> the linktime library search path (-L/usr/bin)?  Perhaps a symlink in
> /usr/lib, pointing to /usr/bin/libfoo.dll is all you need. 
> 
> However!!! Ld uses the following library name search order when hunting
> for -lfoo:
> 
>   libfoo.dll.a
>   foo.dll.a
>   libfoo.a  <<<< NOTE!!
>   libfoo.dll
>   foo.dll

Or that.  Thanks again!  Libtool already provides --disable-static if
the user wants to build and install only the dll parts of the library.

For this to work (that is, in order for me to be able to punt to gcc/ld
in the majority of cases) I must generate dll names that will be
found, so the cygfoo.dll idea is out (Sorry Paul!).

Although this doesn't help ``User 2'' very much, he is no worse off
than before if I change libtool's behaviour in this way.  Here's a
thought:  For each dll using application linked, I could have libtool
install a .bat script to C:/cygwin/launch (or similar) which would set
the PATH environment correctly for that application.  As long as
``User 2'' has the launch directory higher in his PATH than the actual
binary directory, this would guarantee correct dll selection.

This would give ``User 1'' many of the advantages shared libraries
offer on Unix, without sinking into DLL Hell.  Assuming that everyone
buys into it.  The only reason shared libraries work properly on Unix
is that everyone has to agree to conform to the runtime loader's
versioning scheme -- so don't give some excuse about ``if we don't
want to change the core cygwin dll's to conform this won't work''.  On
my linux box, I can move my libc around or drop several incompatible
versions of libc into my filesystem, and my applications will stop
loading the intended libraries too.  No surprises there!

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Gary V. Vaughan]

On Sat, Sep 02, 2000 at 10:19:15PM -0400, Chris Faylor wrote:
> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
> 
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the executable.
> Most Windows packages rely on this and place the DLL with the executable.
> That should solve the problem of finding the "wrong" dll.
> 
> I'm still kind of amazed by all of the furor this discussion is generating,
> given that I don't think we have yet seen a single problem reported.
> 
> If this was a big deal I would have thought that there would be many many
> plaintive wails in this mailing list.
> 
> If the solution to the problem is as simple as placing the DLL with the
> executable then why the heck don't we just do that?  I love being as
> close to UNIX as possible but if it is going to cause problems then
> it makes sense not to do things that way.

<rant>
Why not just statically link all of our applications?  Then we
wouldn't have any problems with wrong dlls being loaded at all!

Everyone agrees that shared libraries on Unix are a good idea, right?
How come so many of us think that the best way to use shared libraries
on Windows is to make them as much like static libraries as we can?
The closest thing to a static library *is* a static library.  Lets get
off the fence here.  If we want static libraries then fine, I'll shut
up and go away.  If we want shared libraries, wouldn't it be cool to
hammer out the easiest (from a man-hours effort point of view) way to
take advantage of the benefits they can offer?

The whole point of a shared library, is that it is shared by the
applications that use it.  You can upgrade all of the applications
that use it by updating the shared library.  You only need to have one
copy in memory.

Putting a copy of all the dll's used by each application into the
directory the application loads from defeats the purpose.  I know dll's
are sucky compared to ELF shared libraries, and that the windows
runtime loader is sucky compared to ld.so.  But wouldn't it be nice to
have some of the advantages shared libraries bring to Unix when we use
cygwin?  I'm even offering to do most of the work by making all the
libtool using packages (i.e. just about everything from gnu.org and a
whole buch of other stuff too) conform to whatever scheme we agree
will work the best.  I'll bet that if we converted the non-libtool
packages that we port to an autoconf/automake/libtool build system,
the upstream maintainers would incorporate the patch into the real
version, and the next release would work on cygwin out of the box.
Assuming we choose a good scheme for libtool built dlls on cygwin.
</rant>

Cheers,
	Grumpy^H^H^H^H^H^HGary =)O|
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Sun, Sep 03, 2000 at 01:27:12PM +0100, Gary V. Vaughan wrote:
>On Sat, Sep 02, 2000 at 10:19:15PM -0400, Chris Faylor wrote:
>> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> >> Since windows-dll
>> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> >> similar, you've got a problem.
>> >
>> >Most definitely.
>> 
>> It is *not* strictly based on the executable path.  It first searches
>> the current directory, then searches the directory containing the executable.
>> Most Windows packages rely on this and place the DLL with the executable.
>> That should solve the problem of finding the "wrong" dll.
>> 
>> I'm still kind of amazed by all of the furor this discussion is generating,
>> given that I don't think we have yet seen a single problem reported.
>> 
>> If this was a big deal I would have thought that there would be many many
>> plaintive wails in this mailing list.
>> 
>> If the solution to the problem is as simple as placing the DLL with the
>> executable then why the heck don't we just do that?  I love being as
>> close to UNIX as possible but if it is going to cause problems then
>> it makes sense not to do things that way.
>
><rant>
>Why not just statically link all of our applications?  Then we
>wouldn't have any problems with wrong dlls being loaded at all!
>
>Everyone agrees that shared libraries on Unix are a good idea, right?
>How come so many of us think that the best way to use shared libraries
>on Windows is to make them as much like static libraries as we can?
>The closest thing to a static library *is* a static library.  Lets get
>off the fence here.  If we want static libraries then fine, I'll shut
>up and go away.  If we want shared libraries, wouldn't it be cool to
>hammer out the easiest (from a man-hours effort point of view) way to
>take advantage of the benefits they can offer?
>
>The whole point of a shared library, is that it is shared by the
>applications that use it.  You can upgrade all of the applications
>that use it by updating the shared library.  You only need to have one
>copy in memory.
>
>Putting a copy of all the dll's used by each application into the
>directory the application loads from defeats the purpose.  I know dll's
>are sucky compared to ELF shared libraries, and that the windows
>runtime loader is sucky compared to ld.so.  But wouldn't it be nice to
>have some of the advantages shared libraries bring to Unix when we use
>cygwin?  I'm even offering to do most of the work by making all the
>libtool using packages (i.e. just about everything from gnu.org and a
>whole buch of other stuff too) conform to whatever scheme we agree
>will work the best.  I'll bet that if we converted the non-libtool
>packages that we port to an autoconf/automake/libtool build system,
>the upstream maintainers would incorporate the patch into the real
>version, and the next release would work on cygwin out of the box.
>Assuming we choose a good scheme for libtool built dlls on cygwin.
></rant>

Are you ranting at me?  Don't bother.

Chuck Wilson has adequately explained why "just put the DLL in
the same directory" isn't a perfect plan.

Regardless, I wasn't advocating putting each executable in its own
directory with a DLL.

My major concern was naming every cygwin DLL "cygsomething.dll".  I
really don't like that idea, especially since it will mean work for
people at Red Hat to accomodate.

If you have a plan that doesn't require changing the name of libz.dll to
something like cyglibz.dll then I have no objections.

I did see the AppPath registry key being mentioned.  I'm not sure how
libtool could make use of that since that is something that is set on
installation of a package.  libtool may be out of the picture at that
point unless you're doing 'make install'.

I think it may be possible to have a dll that is loaded before most
other dlls change the PATH so that something like /usr/lib is first in
the path, removing the /usr/lib prior to execution of 'main()'.  We
could, in fact, even add a front end to kernel32.dll which did this.

This could be a solution for cygwin but I don't know if it addresses the
problem of other packages or not.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Chris Faylor]

On Sun, Sep 03, 2000 at 12:30:18PM -0400, Chris Faylor wrote:
>I think it may be possible to have a dll that is loaded before most
>other dlls change the PATH so that something like /usr/lib is first in
>the path, removing the /usr/lib prior to execution of 'main()'.  We
>could, in fact, even add a front end to kernel32.dll which did this.
>
>This could be a solution for cygwin but I don't know if it addresses the
>problem of other packages or not.

Nevermind.  I've been doing more reading.  Load order != order of execution:

http://msdn.microsoft.com/library/periodic/period99/hood0999.htm

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Alexandre Oliva]

On Sep  3, 2000, "Gary V. Vaughan" <gvv@techie.com> wrote:

>   * When installing a libtool (.la) library:
>       - libfoo.la goes to $prefix/lib
>       - libfoo<iface>.dll goes to $prefix/bin
>       - libfoo.dll.a goes to $prefix/lib
>       - libfoo.a goes to $prefix/lib
      
Nope.  libfoo.la goes wherever -rpath specified when the library was
created; it should be the same directory that is specified at install
time.  This is often $(libdir), but it doesn't have to be.

I don't know how to arrange for an additional directory (bindir) to
be specifiable without introducing an additional command-line option.
Remember, libtool doesn't know about prefix, libdir or bindir, it just
knows about what it's given in the command line.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: DLL naming conventions

[Gary V. Vaughan]

On Sun, Sep 03, 2000 at 12:30:18PM -0400, Chris Faylor wrote:
> On Sun, Sep 03, 2000 at 01:27:12PM +0100, Gary V. Vaughan wrote:
> >
> ><rant>
> >Why not just statically link all of our applications?  Then we
> >wouldn't have any problems with wrong dlls being loaded at all!
> ></rant>
> 
> Are you ranting at me?  Don't bother.

No offence was intended.  I was mostly ranting on the capacity of
Microsoft to remove all the advantages of a system (shared libraries)
but still retain all the loops you have to jump through to use them.

> My major concern was naming every cygwin DLL "cygsomething.dll".  I
> really don't like that idea, especially since it will mean work for
> people at Red Hat to accomodate.

Chuck has talked sense into me here... I no longer think that this
buys us anything.

> I did see the AppPath registry key being mentioned.  I'm not sure how
> libtool could make use of that since that is something that is set on
> installation of a package.  libtool may be out of the picture at that
> point unless you're doing 'make install'.

Bummer =(O|  Does that mean binary packages would need to run a
post-install script to set the AppPath correctly then?  If it was a
boiler plate script, perhaps libtool could generate it if it notices
that the `make install' is moving things to a staging area (for
packaging) as opposed to moving things directly to the live
directories...

> This could be a solution for cygwin but I don't know if it addresses the
> problem of other packages or not.

Paul has shown willing to provide suitable patches for his system, and
I use only cygwin myself.  If I can improve the build system on just
cygwin I will be more than happy.

Cheers,
	Gary.
-- 
  ___              _   ___   __              _         mailto: gvv@techie.com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Current Directory? [Branch from Re: DLL naming conventions]

[David A. Cobb]

Chris Faylor wrote:

> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> Since windows-dll
> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
> >> similar, you've got a problem.
> >
> >Most definitely.
>
> It is *not* strictly based on the executable path.  It first searches
> the current directory, then searches the directory containing the executable.

With the possibility of several processes active and several partitions, etc.,
just like the big boys; what does "current directory" mean?  I only see it when
defining a PIF for a DOS program.

--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Current Directory? [Branch from Re: DLL naming conventions]

[Chris Faylor]

On Mon, Sep 04, 2000 at 06:22:18PM -0400, David A. Cobb wrote:
>Chris Faylor wrote:
>
>> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
>> >> Since windows-dll
>> >> loading is based on the executable path, and not 'LD_LIBRARY_PATH' or
>> >> similar, you've got a problem.
>> >
>> >Most definitely.
>>
>> It is *not* strictly based on the executable path.  It first searches
>> the current directory, then searches the directory containing the executable.
>
>With the possibility of several processes active and several partitions, etc.,
>just like the big boys; what does "current directory" mean?  I only see it when
>defining a PIF for a DOS program.

I actually got the order wrong.  It searches the directory containing
the executable and then the current directory.

As far as what the "current directory" means, it means the directory
you're cd'ed to.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Current Directory? [Branch from Re: DLL naming conventions]

[Bob McGowan]

Chris Faylor wrote:
> 
> On Mon, Sep 04, 2000 at 06:22:18PM -0400, David A. Cobb wrote:
> >Chris Faylor wrote:
> >
> >> On Sat, Sep 02, 2000 at 11:19:25PM +0100, Gary V. Vaughan wrote:
> >> >> Since windows-dll

---

> 
> As far as what the "current directory" means, it means the directory
> you're cd'ed to.
> 
> cgf

I'd like to expand on this, hopefully to add clarity.  The above is
absolutely correct, for an interactive foreground shell session. 
Another way to say it is that the "current directory" is what you would
get if you were to open the file named "." (dot, period...) in an
application (which includes the shells).

Additionally, since any particular application may be run in the
background, and may also change directory, it is possible to have
several "current directories", depending on which of the running
applications you are referring to.

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Current Directory? [Branch from Re: DLL naming conventions]

[David A. Cobb]

Bob McGowan wrote:

> I'd like to expand on this, hopefully to add clarity.  The above is
> absolutely correct, for an interactive foreground shell session.
> Another way to say it is that the "current directory" is what you would
> get if you were to open the file named "." (dot, period...) in an
> application (which includes the shells).
>
> Additionally, since any particular application may be run in the
> background, and may also change directory, it is possible to have
> several "current directories", depending on which of the running
> applications you are referring to.
>

The "Current Directory" then, must be a property/attribute of the "Current
Process."  Is that correct?  With respect to the operator, it is relative
to the
current top window?

In other words, when I launch a program the cd is established by the
[shell] process in which I execute the launch command.  Subsequently, the
running
process may change it internally.  If I focus somewhere else, "my" current
directory changes, but that's irrelevant to the program I launched before.

Have I got it?


>
> --
> Bob McGowan
> Staff Software Quality Engineer
> VERITAS Software
> rmcgowan@veritas.com
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
David A. Cobb, Software Engineer, Public Access Advocate
"Don't buy or use crappy software"
"By the grace of God I am a Christian man,
 by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.]



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Current Directory? [Branch from Re: DLL naming conventions]

[Bob McGowan]

"David A. Cobb" wrote:
> 
> Bob McGowan wrote:
> 
> > I'd like to expand on this, hopefully to add clarity.  The above is
---
The one thing I did not say I was doing, was looking at this from a
"command line" orientation.  Windowing software adds complexity since
the user now is seeing multiple instances of applications.

> 
> The "Current Directory" then, must be a property/attribute of the "Current
> Process."  Is that correct?  With respect to the operator, it is relative
> to the current top window?

I'm not sure what the definition should be for "Current Process".  If by
that you mean the currently active, top window, then basically, yes. 
But, each and every process has a "current directory", whether or not it
is currently running, whether or not it is the "top window", etc.  You
are correct that from the perspective of the operator, the operator's
"current directory" will be that of the top window.

> In other words, when I launch a program the cd is established by the
> [shell] process in which I execute the launch command.  Subsequently, the
> running
> process may change it internally.  If I focus somewhere else, "my" current
> directory changes, but that's irrelevant to the program I launched before.
> 
> Have I got it?
> 

I think you've got it ;)

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com