gcc 3.3.1-3, loading .la files from gcj-compiled apps

gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Marcus G. Daniels]

Would it be possible to add a -D_WIN32 to the libjava/libltdl Makefile 
for Cygwin?  Then the LoadLibrary support will get compiled-in, and 
dynamic libraries can be loaded into GCJ apps.  If this is done, then a 
__CYGWIN__ conditional is needed in ltdl.c in order to first normalize 
the path for Windows, e.g. here's how I hacked it in my copy (not 
intended as a patch, just for illustration).   Also, I found I had to 
duplicate the stack copy of `buf' in java::lang::Runtime:_load in order 
to avoid it getting wiped out from the the exception getting caught.  
Please see the second illustrative patch.  With these two changes, I can 
use LoadLibrary in GCJ-compiled apps with libtool dynamic libraries in 
the same way that Sun JDK can load ordinary DLLs.

*** ltdl.c-orig    Sun Nov  2 11:12:58 2003
--- ltdl.c    Sun Nov  2 11:13:23 2003
***************
*** 479,486 ****
          strcpy(searchname, filename);
          strcat(searchname, ".");
      }
!
!     module = LoadLibrary(searchname);
      lt_dlfree(searchname);
     
      /* libltdl expects this function to fail if it is unable
--- 479,490 ----
          strcpy(searchname, filename);
          strcat(searchname, ".");
      }
!         {
!            char buf[1024];
!           
!            cygwin_conv_to_win32_path (searchname, buf);
!        module = LoadLibrary(buf);
!         }
      lt_dlfree(searchname);
     
      /* libltdl expects this function to fail if it is unable


*** natRuntime.cc-orig    Sun Nov  2 08:58:56 2003
--- natRuntime.cc    Sun Nov  2 11:59:29 2003
***************
*** 174,180 ****
    jsize total = JvGetStringUTFRegion (path, 0, path->length(), 
&buf[offset]);
    buf[offset + total] = '\0';
 
!   char *lib_name = buf;
 
    if (do_search)
      {
--- 174,180 ----
    jsize total = JvGetStringUTFRegion (path, 0, path->length(), 
&buf[offset]);
    buf[offset + total] = '\0';
 
!   char *lib_name = strdup (buf);
 
    if (do_search)
      {


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Christopher Faylor]

On Sun, Nov 02, 2003 at 12:20:47PM -0700, Marcus G. Daniels wrote:
>Would it be possible to add a -D_WIN32 to the libjava/libltdl Makefile 
>for Cygwin?  Then the LoadLibrary support will get compiled-in, and 
>dynamic libraries can be loaded into GCJ apps.

No.  If there is dynamic linking to be done it should work through
dlopen and pals.  Defining _WIN32 is not the way to accomplish this.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

libltdl + dlopen/LoadLibrary [Was: Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps]

[Charles Wilson]

Christopher Faylor wrote:

> On Sun, Nov 02, 2003 at 12:20:47PM -0700, Marcus G. Daniels wrote:
> 
>>Would it be possible to add a -D_WIN32 to the libjava/libltdl Makefile 
>>for Cygwin?  Then the LoadLibrary support will get compiled-in, and 
>>dynamic libraries can be loaded into GCJ apps.
> 
> 
> No.  If there is dynamic linking to be done it should work through
> dlopen and pals.  Defining _WIN32 is not the way to accomplish this.
> 

Hmmm...  I've been having problems compiling cvs-m4 which HEAVILY uses 
the libltdl library-loading functionality.  I wonder if it could be 
related to this:

 From ltdl.c:
#if __CYGWIN__
   {
     char wpath[MAX_PATH];
     cygwin_conv_to_full_win32_path(searchname, wpath);
     module = LoadLibrary(wpath);
   }
#else
   module = LoadLibrary (searchname);
#endif
   LT_DLFREE (searchname);

It appears that current libtool does in fact use LoadLibrary and not 
dlopen.  This worked fine in the past (perhaps pre-1.5.0?) but appears 
to not work as well anymore.

Should the module-loading functionality in libtoool for cygwin be 
reworked to use dlopen instead?

--
Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: libltdl + dlopen/LoadLibrary [Was: Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps]

[Christopher Faylor]

On Sun, Nov 02, 2003 at 03:13:56PM -0500, Charles Wilson wrote:
>Should the module-loading functionality in libtoool for cygwin be 
>reworked to use dlopen instead?

Without a doubt.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Tom Tromey]

>>>>> "Marcus" == Marcus G Daniels <mgd@santafe.edu> writes:

Marcus> Would it be possible to add a -D_WIN32 to the libjava/libltdl
Marcus> Makefile for Cygwin?

It looks like it would be a bit more in line with existing code to
just add it to libltdl/ltdl.h.

Could you look at how the upstream libltdl handles it?  We
occasionally talk about importing a new version, I wonder if that
would fix this for you.

Marcus> Also, I found I had to duplicate the stack copy of `buf' in
Marcus> java::lang::Runtime:_load in order to avoid it getting wiped
Marcus> out from the the exception getting caught.

Could you be more explicit about this?  Catching an exception
shouldn't trash this array... if it does, doesn't that mean there is a
bug somewhere else?

The ltdl.c patch looks ok-ish, provided (as you noted) it is cleaned
up to be cygwin specific.  Again, ideally we'd do this via the
upstream libltdl.

Tom

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Christopher Faylor]

[reply-to set]
On Fri, Nov 07, 2003 at 01:31:52PM -0700, Tom Tromey wrote:
>>>>>> "Marcus" == Marcus G Daniels <mgd@santafe.edu> writes:
>
>Marcus> Would it be possible to add a -D_WIN32 to the libjava/libltdl
>Marcus> Makefile for Cygwin?
>
>It looks like it would be a bit more in line with existing code to
>just add it to libltdl/ltdl.h.

Please don't do this.  Cygwin is not WIN32.  We explicitly don't set
_WIN32 in cygwin for a reason.  Why is it required for Java?  Why isn't
normal UNIX code being used?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Sat, 2003-11-08 at 07:31, Tom Tromey wrote:
> >>>>> "Marcus" == Marcus G Daniels <mgd@santafe.edu> writes:
> 
> Marcus> Would it be possible to add a -D_WIN32 to the libjava/libltdl
> Marcus> Makefile for Cygwin?

Just caught up with this. -DWIN32 is usually wrong for cygwin. Cygwin
programs should use dlopen etc al. The only time win32 specific calls
are appropriate for cywgin, is when you are doing native non-cygwin
supported stuff.

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Marcus G. Daniels]

Tom Tromey wrote:

>>>>>>"Marcus" == Marcus G Daniels <mgd@santafe.edu> writes:
>>>>>>            
>>>>>>
>
>Marcus> Would it be possible to add a -D_WIN32 to the libjava/libltdl
>Marcus> Makefile for Cygwin?
>
>It looks like it would be a bit more in line with existing code to
>just add it to libltdl/ltdl.h.
>
>Could you look at how the upstream libltdl handles it?  We
>occasionally talk about importing a new version, I wonder if that
>would fix this for you.
>  
>
As of yesterday, I believe Charles Wilson has convinced the libtool 
maintainers to install the needed patches.  It uses dlopen if it can, 
and then falls back to LoadLibrary if that fails.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Charles Wilson]

Marcus G. Daniels wrote:

>>
> As of yesterday, I believe Charles Wilson has convinced the libtool 
> maintainers to install the needed patches.  It uses dlopen if it can, 
> and then falls back to LoadLibrary if that fails.
> 

Actually, that change is all Gary V. Vaughan.

Here's the story: contrary to my post in this thread from two days ago, 
current cygwin libltdl DOES use dlopen exclusively.  What confused me 
was that there is some compatibility code in the LoadLibrary section, 
which in the distant past was used by libltdl on cygwin.

(Thus, if gcj/your-package uses an older libtool/older libltdl, it is 
possible you created your loadable modules in old, LoadLibrary mode. 
But for the last year or so, and in official libtool-1.5, cygwin libtool 
has been dlopen-only.)

I submitted a patch which removed all of the (dead) LoadLibrary/cygwin 
compatibility stuff.  Because it was not used at all, in current 
libtool/libltdl.

GVV went one better, and re-activated the LoadLibrary stuff, with cygwin 
compatibility code, as a FALLBACK option if-and-only-if dlopen on cygwin 
fails.  THAT is what got committed to libtool CVS HEAD, and it's Gary's 
contribution, not mine.

Now, whether this fixes your problem or just makes it worse, I don't know.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Sat, 2003-11-08 at 12:11, Charles Wilson wrote:
> GVV went one better, and re-activated the LoadLibrary stuff, with cygwin 
> compatibility code, as a FALLBACK option if-and-only-if dlopen on cygwin 
> fails.  THAT is what got committed to libtool CVS HEAD, and it's Gary's 
> contribution, not mine.
> 
> Now, whether this fixes your problem or just makes it worse, I don't know.

I suspect it'll make it worse, as it may well interfere with fork().

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Charles Wilson]

Robert Collins wrote:
> On Sat, 2003-11-08 at 12:11, Charles Wilson wrote:
> 
>>GVV went one better, and re-activated the LoadLibrary stuff, with cygwin 
>>compatibility code, as a FALLBACK option if-and-only-if dlopen on cygwin 
>>fails.  THAT is what got committed to libtool CVS HEAD, and it's Gary's 
>>contribution, not mine.
>>
>>Now, whether this fixes your problem or just makes it worse, I don't know.
> 
> 
> I suspect it'll make it worse, as it may well interfere with fork().

Hmm.  I wonder if "The Right Thing To Do" is to ensure that libjava's 
version of ltdl.c is uptodate -- that is, taken from libtool-1.5 and not 
1.4.x, and then rebuild libjava, the modules, etc.

Or rebuild libjava so that it uses the system-installed version of 
cygltdl-3.dll and not a self-compiled one.

Then, we'll at LEAST know that everything is speaking the same dlopen 
language.

Plus, can somebody do an strace on the program that fails to load the 
.la files?  And make sure that dlopen & friends ARE in fact being 
called, as they should be on the cygwin platform?  (That is, instead of 
asking for LoadLibrary workarounds, let's make sure that we're actually 
using -- and that the modules themselves are expecting -- the 
cygwin-provided, fork()-friendly dlopen stuff).

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Sat, 2003-11-08 at 12:33, Charles Wilson wrote:

> the 
> cygwin-provided, fork()-friendly dlopen stuff).

Just for clarity, the fork() support in dlopen is really just tracking
base addresses and order of opening.(from slightly rusty memory).

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Marcus G. Daniels]

Charles Wilson wrote:

> Or rebuild libjava so that it uses the system-installed version of 
> cygltdl-3.dll and not a self-compiled one.

It looks to me like everything would work (assuming dlopen works), 
provided the libjava linked against the Cygwin libltdl instead of the 
one it subsumes from itself.  The problem in the libjava/libltldl in 
Cygwin's GCC 3.3.1-3 source distribution is that the HAVE_LIBDL code is 
disabled with a special case for Cygwin in order to supress some 
spurious error message. And unfortunately the fallback to LoadLibrary 
doesn't happen either because _WIN32 is not set.

While it would be good to update GCC at some point, this idea of getting 
GCC to take Cygwin's libltldl would seem to be the most flexible thing 
to have happen... (Assuming there are othher important reasons for 
having that libtldl DLL.)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Tom Tromey]

>>>>> "Charles" == Charles Wilson <cygwin@cwilson.fastmail.fm> writes:

Charles> Hmm.  I wonder if "The Right Thing To Do" is to ensure that libjava's
Charles> version of ltdl.c is uptodate -- that is, taken from libtool-1.5 and
Charles> not 1.4.x, and then rebuild libjava, the modules, etc.

I think so.  Care to try upgrading the libltdl in libjava?

Tom

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: gcc 3.3.1-3, loading .la files from gcj-compiled apps

[Charles Wilson]

Tom Tromey wrote:

> Charles> Hmm.  I wonder if "The Right Thing To Do" is to ensure that libjava's
> Charles> version of ltdl.c is uptodate -- that is, taken from libtool-1.5 and
> Charles> not 1.4.x, and then rebuild libjava, the modules, etc.
> 
> I think so.  Care to try upgrading the libltdl in libjava?

Not even a little bit.  I don't use java.  I've never been able to 
successfully triple-bootstrap gcc on cygwin.  And my only windows/cygwin 
computer would take about two days to do so, even if it did succeed.

I'll leave the actual implementation/investigation of this fix -- if it 
is a fix -- to those that are directly affected by it.

--
Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/