From: Mohan E. <gnu...@th...> - 2004-09-13 12:20:06
|
Hi Andrew, > > Rutger Ovidius pointed out off list that he has problems > > building libgcj under Cygwin because of command-line > > length limitations that used to be worked around when > > building libgcj.la. I haven't looked into this much but > > was wondering if this rang a bell with anyone.... > >Do we know why this is? Doesn't Cygwin use bash? Cygwin uses bash too, but probably has more severe command-line- length limitations which expose this issue than say bash on RH 9.0. I don't build on Windows, but recall that I was surprised to see the massive link command line on Linux and sort of wondered out loud why things didn't break. MinGW folks, has anyone run across this when building gcj on Cygwin or MSYS?: - http://gcc.gnu.org/ml/java/2004-09/msg00085.html - http://gcc.gnu.org/ml/java/2004-09/msg00088.html -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Christopher F. <me...@cg...> - 2004-09-13 19:58:13
|
On Mon, Sep 13, 2004 at 07:19:21AM -0500, Mohan Embar wrote: >Hi Andrew, > >> > Rutger Ovidius pointed out off list that he has problems >> > building libgcj under Cygwin because of command-line >> > length limitations that used to be worked around when >> > building libgcj.la. I haven't looked into this much but >> > was wondering if this rang a bell with anyone.... >> >>Do we know why this is? Doesn't Cygwin use bash? > >Cygwin uses bash too, but probably has more severe command-line- >length limitations which expose this issue than say bash on RH 9.0. >I don't build on Windows, but recall that I was surprised to see >the massive link command line on Linux and sort of wondered out >loud why things didn't break. Cygwin has a '-X' mount option which allows longer command line lengths than windows provides. I don't know if it would also work on msys. cgf |
From: Michael K. <kon...@gm...> - 2004-09-13 12:28:52
|
On Monday 13 September 2004 14:19, Mohan Embar wrote: > Hi Andrew, > > > > Rutger Ovidius pointed out off list that he has problems > > > building libgcj under Cygwin because of command-line > > > length limitations that used to be worked around when > > > building libgcj.la. I haven't looked into this much but > > > was wondering if this rang a bell with anyone.... > > > >Do we know why this is? Doesn't Cygwin use bash? > > Cygwin uses bash too, but probably has more severe command-line- > length limitations which expose this issue than say bash on RH 9.0. > I don't build on Windows, but recall that I was surprised to see > the massive link command line on Linux and sort of wondered out > loud why things didn't break. > > MinGW folks, has anyone run across this when building gcj > on Cygwin or MSYS?: > > - http://gcc.gnu.org/ml/java/2004-09/msg00085.html > - http://gcc.gnu.org/ml/java/2004-09/msg00088.html I got a report from Kelley Cook when I provided my automake 1.9 patch for review. I did a little change but he never replied if it works or not. Michael |
From: Simon L. <sim...@wo...> - 2004-09-13 13:43:58
|
On Monday 13 September 2004 13:19, Mohan Embar wrote: > MinGW folks, has anyone run across this when building gcj > on Cygwin or MSYS?: > I have (Although you probably couldn't define me as a MinGW person!). I've been Building under MinGW/MSYS. I couldn't get the 3.4 branch to build without getting far to involved in the errors being produced. So I tried 3.5 - All I needed to do to get that to build was change the maximum command line length setting variable in the libtool script within the mingw32/libjava directory. I've put it down to something probably stupidly low (2048) which forced libtool into incremental linking. I'm incredibly impressed with the whole lot. I really didn't expect the whole GCJ environment to work as well as it has under Win32 when I suggested it as a technological solution to a problem we had.... Everyone involved has done me proud! Simon., -- -------------------------------------------------------------------------- Simon Levitt, Principal Development Engineer @ WorldPay, WorldPay Centre, The Science Park, Milton Rd., Cambridge, CB4 0WE, ENGLAND Sim...@wo... Ph:+44(0)1223 715151 F:+44(0)1223 715157 ------------------------- http://www.worldpay.com/ ----------------------- |
From: Andrew H. <ap...@re...> - 2004-09-13 14:33:16
|
Simon Levitt writes: > On Monday 13 September 2004 13:19, Mohan Embar wrote: > > MinGW folks, has anyone run across this when building gcj > > on Cygwin or MSYS?: > > > I have (Although you probably couldn't define me as a MinGW person!). > I've been Building under MinGW/MSYS. > > I couldn't get the 3.4 branch to build without getting far to involved in the > errors being produced. > So I tried 3.5 - All I needed to do to get that to build was change the > maximum command line length setting variable in the libtool script within the > mingw32/libjava directory. > > I've put it down to something probably stupidly low (2048) which forced > libtool into incremental linking. OK. We should get a patch in for this. > I'm incredibly impressed with the whole lot. I really didn't expect the whole > GCJ environment to work as well as it has under Win32 when I suggested it as > a technological solution to a problem we had.... Excellent. Andrew. |
From: Aaron W. L. <aar...@aa...> - 2004-09-21 20:36:58
|
Simon Levitt wrote: > On Monday 13 September 2004 13:19, Mohan Embar wrote: > >>MinGW folks, has anyone run across this when building gcj >>on Cygwin or MSYS?: >> > I have (Although you probably couldn't define me as a MinGW person!). > I've been Building under MinGW/MSYS. > > I couldn't get the 3.4 branch to build without getting far to involved in the > errors being produced. > So I tried 3.5 - All I needed to do to get that to build was change the > maximum command line length setting variable in the libtool script within the > mingw32/libjava directory. > > I've put it down to something probably stupidly low (2048) which forced > libtool into incremental linking. Can you tell me exactly how you did this? I've tried modifying both all instances of max_cmd_len in libjava/dlltool, and modifying ltconfig directly, all before configuring and building, and it does not seem to stop make from attempting to pass that huge command line. Aaron W. LaFramboise |
From: Aaron W. L. <aar...@aa...> - 2004-09-21 21:41:27
|
Aaron W. LaFramboise wrote: > Simon Levitt wrote: > >>I've put it down to something probably stupidly low (2048) which forced >>libtool into incremental linking. > > Can you tell me exactly how you did this? I've tried modifying both all > instances of max_cmd_len in libjava/dlltool, and modifying ltconfig > directly, all before configuring and building, and it does not seem to > stop make from attempting to pass that huge command line. I looked at this in more detail. The problem happens before libtool is even invoked, which is why max_cmd_len doesn't appear to make a difference. make is trying to invoke libtool with all of the dependencies. If that invokation were successful, which it isn't, libtool would then do the correct partial link. But it doesn't get that far. I think something needs to tell automake about max_cmd_len also so that it does not cause make to exceed the maximum length. I'm not entirely sure how this would work though, because it seems like it might mean requiring automake to know about partial links also. Aaron W. LaFramboise |
From: Earnie B. <ea...@us...> - 2004-09-21 23:38:05
|
You can change max_cmd_len in work around fashion in the generated libtool script. Be sure to change all occurrences in the script, there are three or four. Earnie Aaron W. LaFramboise wrote: >Aaron W. LaFramboise wrote: > > >>Simon Levitt wrote: >> >> >> >>>I've put it down to something probably stupidly low (2048) which forced >>>libtool into incremental linking. >>> >>> >>Can you tell me exactly how you did this? I've tried modifying both all >>instances of max_cmd_len in libjava/dlltool, and modifying ltconfig >>directly, all before configuring and building, and it does not seem to >>stop make from attempting to pass that huge command line. >> >> > >I looked at this in more detail. The problem happens before libtool is >even invoked, which is why max_cmd_len doesn't appear to make a difference. > >make is trying to invoke libtool with all of the dependencies. If that >invokation were successful, which it isn't, libtool would then do the >correct partial link. But it doesn't get that far. I think something >needs to tell automake about max_cmd_len also so that it does not cause >make to exceed the maximum length. I'm not entirely sure how this would >work though, because it seems like it might mean requiring automake to >know about partial links also. > >Aaron W. LaFramboise > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >MinGW-dvlpr mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > > > > > -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Aaron W. L. <aar...@aa...> - 2004-09-22 01:32:44
|
Earnie Boyd wrote: > You can change max_cmd_len in work around fashion in the generated > libtool script. Be sure to change all occurrences in the script, there > are three or four. Whats strange is that this does not appear to work for me. The trouble is actually before libtool is invoked, this line in the Makefile: $(libgcj_la_LINK) -rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(libgcj_la_OBJECTS) $(libgcj_la_LIBADD) $(LIBS) $(libgcj_la_OBJECTS) expands to a huge list of objects, and so make fails while trying to execute sh to run this line, before libtool is even called. I'm using Cygwin make. Perhaps another one would work better? I tried both MinGW make and MSYS make, but both of those didn't work at all for other reasons I have not investigated. Aaron W. LaFramboise |
From: Simon L. <sim...@wo...> - 2004-09-22 08:42:09
|
On Wednesday 22 September 2004 02:33, Aaron W. LaFramboise wrote: > $(libgcj_la_OBJECTS) expands to a huge list of objects, and so make > fails while trying to execute sh to run this line, before libtool is > even called. > When I was building it all I did wonder why the la line worked and the link failed. It's occuring to me that it might be a function of the path underwhich its being built, so in my case the command gets truncated (by amasing luck) just after a full filename, so the command actually works but with less files passed to it. That in turn I suppose may mean my built libgcj.a doesn't contain all the files it should! But I can't say I've noticed that! > I tried both MinGW make and MSYS make, but both of those didn't work at all > for other reasons I have not investigated. > I'm using MSYS make. But your probably right in that it makes little difference. Simon., -- -------------------------------------------------------------------------- Simon Levitt, Principal Development Engineer @ WorldPay, WorldPay Centre, The Science Park, Milton Rd., Cambridge, CB4 0WE, ENGLAND Sim...@wo... Ph:+44(0)1223 715151 F:+44(0)1223 715157 ------------------------- http://www.worldpay.com/ ----------------------- |
From: Aaron W. L. <aar...@aa...> - 2004-09-23 05:13:41
|
Simon Levitt wrote: > On Wednesday 22 September 2004 02:33, Aaron W. LaFramboise wrote: > >>$(libgcj_la_OBJECTS) expands to a huge list of objects, and so make >>fails while trying to execute sh to run this line, before libtool is >>even called. > > When I was building it all I did wonder why the la line worked and the link > failed. > > It's occuring to me that it might be a function of the path underwhich its > being built, so in my case the command gets truncated (by amasing luck) just > after a full filename, so the command actually works but with less files > passed to it. > > That in turn I suppose may mean my built libgcj.a doesn't contain all the > files it should! But I can't say I've noticed that! Well, I finally got it to work using these steps: 1) I edited the toplevel ltconfig to cause max_cmd_len to be set to a reasonable value. (Alternately, it could be modified directly in the generated libtool script.) 2) I bootstrapped until I hit the failure in the libgcj.la rule. 3) I reran make on the libgcj.la rule, piping output to a file. Then I trimmed the file with an editor so it only contained a single line with all of the arguments to libtool (starting with --tag). I used this command to evaluate the `` substitution: eval echo `cat trimmed-output` > libtool-options 4) I backed up libtool, then added the following command as the second line in the file to set libtool's arguments: set -- `cat libtool-options` 5) I reran the libgcj.la rule. 6) I restored libtool, and restarted the bootstrap As far as fixing the problem, the trouble here ultimately lies in autotools: 1) libtool's max command line length test isn't good enough. In addition to checking maximum byte size of arguments, it also needs to check for maximum number of arguments (ie argc) and maximum length of an individual argument. This would be enough to make any system happy, I think. 2) automake also needs to apply the max command length. In cases where the command line is insufficient, the object list needs to be put into a file, and passed indirectly to libtool. Unfortunately, I know next to nothing about autotools internals, and to be honest, they seem quite intimidating. Its possible that automake already supports this somehow, but I don't see anything obvious in the docs. Anyway, in the meantime, hopefully this workaround will help someone else who had my problem. Aaron W. LaFramboise |
From: Michael K. <kon...@gm...> - 2004-09-22 09:04:05
|
On Wednesday 22 September 2004 10:41, Simon Levitt wrote: > On Wednesday 22 September 2004 02:33, Aaron W. LaFramboise wrote: > > $(libgcj_la_OBJECTS) expands to a huge list of objects, and so > > make fails while trying to execute sh to run this line, before > > libtool is even called. > > When I was building it all I did wonder why the la line worked and > the link failed. > > It's occuring to me that it might be a function of the path > underwhich its being built, so in my case the command gets > truncated (by amasing luck) just after a full filename, so the > command actually works but with less files passed to it. > > That in turn I suppose may mean my built libgcj.a doesn't contain > all the files it should! But I can't say I've noticed that! > > > I tried both MinGW make and MSYS make, but both of those didn't > > work at all for other reasons I have not investigated. > > I'm using MSYS make. But your probably right in that it makes > little difference. Note that GCC depends on GNU make. I dont know of any of those is derived from it. Michael |