Date: Mon, 7 Sep 1998 11:19:09 +0200 (WET) From: Andris Pavenis To: Eli Zaretskii cc: djgpp-workers AT delorie DOT com Subject: Re: egcs-1.1a uploaded In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 7 Sep 1998, Eli Zaretskii wrote: > > The following comments are based solely on reading the message about > the port; I didn't try using EGCS yet. > > On Friday, 4 Sep 1998, Andris Pavenis wrote: > > > stl_algobase.h -> stlalgobase.h > > stl_hash_map.h -> stlhashmap.h > > stl_hash_set.h -> stlhashset.h > > stl_hashtable.h -> stlhashtable.h > > stl_multiset.h -> stlmultiset.h > > Of these, why the first and the last needed to be renamed? Do they > clash with some other header files, which are not shown here? I think the following output from Linux (where renaming is not needed of course) answers this question: hal:~# cd /usr/include/g++ hal:/usr/include/g++# ls stl_algo* stl_algo.h stl_algobase.h hal:/usr/include/g++# ls stl_mult* stl_multimap.h stl_multiset.h hal:/usr/include/g++# > > > The DJGPP distribution of g++ and libg++ already come with these > > translation files, but they are currently not used. To use them, you > > have to modify your specs file to add the "-remap" switch to the > > call to cpp > > Is there any reason not to put -remap into specs by default? Since > the specs file is now specific to the compiler and installs into a > compiler-specific directory, using -remap doesn't seem to interfere > with anything, right? I think it would be possible. Only question here: how big is possibility to get problems in case of bad installation. DJDEV contains specs in $DJDIR/lib which can interfere with compiler-specific one if $DJDIR/lib is searched before compiler-specific directory > > You need LFN support to build egcs-1.1a from current sources (don't > > even try to do this when LFN support is not available, this will not > > work). > > I would strongly suggest to fix that. Many people still use plain > DOS, even for development, and it isn't nice to prevent them from > rebuilding the compiler, especially since EGCS, as an experimental > version, will probably have more bugs to be corrected. > > Are the LFN problems that hard to fix? What could possibly be so hard > to make them right there? Similar problems were handled in every > other DJGPP port, so I'd expect this one to be no harder. Yes it would be nice. I can only mention that in sources of port of gcc-2.8.1 some things were broken when makeing them build without LFN support (fortunate this caused only unnecesary rebuilding some parts each time) > > > The sources are _NOT_ the complete sources like the original > > egcs-1.1a distribution. I have removed many files to save disk space > > which are not needed for the DJGPP port. > > I think this is a bad idea. Consider somebody who would want to add a > feature to the DJGPP port which is supported on other platforms, or > build a cross-compiler from this version: they *will* need some of the > ``unneeded'' files, and it is a pain in the lower back to fetch the > full EGCS distribution (that might not be available by then, given the > speed they release new versions) and then merge the two distributions. > The cursing this will trigger will be heard from here to Latvia ;-). We still can download all original releases (and even all snapshots) of egcs from ftp.cygnus.com and mirrors. I included bash script that updates egcs-1.1 sources for DJGPP (it is only necessary to delete part that cleans source directory from unneeded sources). Maybe it would be better to split this script into 2 parts. > It is okay to provide a smaller source distribution for those who > don't need the rest, but please at least let there be a separate zip > file with all the rest, at the same site, so those who need it could > have it. > > > Now you run make by typing > > sh djmake.sh [any-additional-parameter] > > Does the build process compile the compiler twice: once with an > existing gcc, and then again with itself? If not, maybe you should > suggest people to recompile the compiler after installing the initial > version, since the usual GCC build procedure actually does it in two > stages. Unfortunatelly ./djmake.sh bootstrap will not work. It may be really better to suggest to build egcs twice. Andris