This is the mail archive of the cygwin-developers mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Aug 18 07:51, Ryan Johnson wrote:What if you just allocated a 128-byte string (perhaps one containing a lot of leading or trailing whitespace) for each dll at link time, then clobbered it in place with the true dependency later? That wouldn't really waste much space and would give a lot of flexibility, since we wouldn't have to mess with the layout of sections or tables within sections.On 18/08/2011 5:20 AM, Corinna Vinschen wrote:So, nobody except Earnie is interested in the way dlopen opens shared objects? Nobody even replied to the idea of the pseudo algorithm below. Does really nobody care?The below looks fine to me, but I really didn't feel qualified to comment. I had been lurking on this thread because I really don't know much about the ins and outs of the Windows loader...
That said, it seemed from a different part of the thread that it should be possible to wire in relative ../lib/ paths for dlls in such a way that we'd no longer need to keep them in bin. It seems like that would be a good avenue to pursue, because then the normal ../lib and ../lib64 conventions would solve the problem of a mixed 32/64-bit distribution pretty nicely. Maybe we could evenUnfortunately, it doesn't seem to be really feasible to hardcode ../lib/my_beloved.dll in executables and other DLLs. The problem is, at the time of building the DLL you don't really know if it will be installed in ../lib. This is typically only known in the `make install' stage, which is a bit too late. I don't see an easy way to automate this behaviour :(
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |