[an error occurred while processing this directive]
Node:<a name="Changing">Changing</a>,
Next:<a rel=next href="faq22_4.html">Packages</a>,
Previous:<a rel=previous href="faq22_2.html">g++.exe</a>,
Up:<a rel=up href="faq22.html">Miscellany</a>
<br>

<h2>22.3 How to change a DJGPP package?</h2>

<p><em><strong>Q</strong>: I want to change cc1.  How do I do this?</em>

<br><p>
<p><em><strong>Q</strong>: How do I fix a bug/add a feature to one of the DJGPP programs?</em>

<br><p>
<p><em><strong>Q</strong>: How should I produce patches for DJGPP programs I want to submit,
and to whom should I submit them?</em>

<br><p>
<p><strong>A</strong>:  First, get the sources.  These are called <code>*s.zip</code> in the
DJGPP distribution.  The C Library sources are in
<code>djlsr203.zip</code>.  Some sources are too big, and
might be split into multiple zips, all of which must be unzipped to get
a complete source distribution, like this:

<pre> em1934s1.zip
 em1934s2.zip
 em1934s3.zip
</pre>

<p>All sources are shipped in ready-to-build form.  Any diffs that come
with the source distribution, like the files called <code>DIFFS</code>, have
already been applied, and any configuration scripts and/or batch files
have been run already; you don't need to run them again.

<p>Next, try to build the program without changing it.  Look for a file
called <code>README.dos</code> or <code>README.djgpp</code>: it should explain the
build procedure and list any optional packages you need to install for
that.

<p>If such a <code>README</code> file is unavailable, you will have to poke
around and figure things out for yourself; here are some hints to help
you out:

<ul>
<li>A file called <code>Makefile</code> or <code>makefile</code> probably means you
could just type <kbd>make</kbd>.

<li>Some packages will have a <code>CONFIGUR.BAT</code> file, possibly in a
subdirectory called <code>djgpp/</code> or <code>pc/</code>; if so, run it first.

<li>If there is a <code>MAKE.BAT</code> file, run it; if not, look for a file
named <code>MAKEFILE.DJ</code> or <code>MAKEFILE.DJG</code>; sometimes these will be
in a subdirectory called <code>dos/</code>, or <code>msdos/</code>, or <code>pc/</code>. 
If there is such a file, then type, e.g., <kbd>make -f makefile.djg</kbd>, if
not, just say <kbd>make</kbd> and see what happens. 
</ul>

<p>The reason for an apparent lack of a standard here is that different
packages were ported to DJGPP by different people, as best as they saw
fit.

<p>After you've successfully built the program, make your fixes and build
the program the same way you did before.

<p>Note that generally to build these programs, you must have the <a href="ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/mak3781b.zip">GNU Make program</a>,
installed, and some makefiles require that you install additional
development utilities, like the <a href="ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/sed302b.zip"><small>SED</small> editor</a>. 
Sometimes the makefiles won't even run under <code>COMMAND.COM</code> (they
require a smarter shell).  In that case, either get a better shell, or
convert the makefile to be runnable by <code>COMMAND.COM</code>, or do the
required steps manually.  If the Makefile is too complex for you and you
can't figure out what are the necessary commands, invoke make with
<code>-n</code> switch and see what it would have done.

<p>If your machine lacks floating-point hardware (like a 386 without a 387,
or a 486SX), then you should know that current versions of GNU Sed and
GNU Make issue floating point instructions, so you will have to make
provisions for loading an emulator, see above, <a href="faq11_1.html">FP Emulation</a>.  The port of Make 3.75
and later can be built so that it doesn't issue FP instructions, but you
will have to get the sources and recompile Make first, as the stock
version wasn't configured in that way.

<p>If you think that you found a bug in one of the programs or libraries
written for DJGPP (e.g. the C library, CWSDPMI, symify, etc.) be sure to
check the <a href="http://www.delorie.com/djgpp/bugs/">list of known bugs</a>.  If
your bug is not there, you can later submit it to the bug-tracking
system.

<p>Before you submit a bug report, please make every effort to verify that
your bug is not caused by incorrect usage, or by problems in your DJGPP
installation.  Reports such as "All DJGPP programs crash" or "I
cannot compile any program" are clearly not bugs, because these things
work for many hundreds of DJGPP users every day; so either your system
setup is messed up or you invoke programs incorrectly.

<p>If you can investigate the cause of the bug and find a solution that
makes it go away, submit a bug report with all the details.  If you
cannot find the cause(s), I suggest posting your problem description to
the news group and asking people to verify that it is indeed a bug,
before you submit a bug report.  The bug-tracking system includes a list
of all known bugs, many of them with solutions or work-arounds; please
check them before creating a new bug report.

<p>Patches to DJGPP programs and ports should be sent to the person who
maintains the relevant package.  Patches for the C library, utilities
and other software which comes with the <code>djdevNNN.zip</code> distribution
should be sent to the <a href="mailto:djgpp-workers@delorie.com">DJGPP developers mailing list</a>; please send them as plain text, not as
binary attachments.

<p>If you don't know who maintains a particular package or port, post the
patches to the <a href="news:comp.os.msdos.djgpp">comp.os.msdos.djgpp news group</a>, since the maintainer is most
probably reading that group.

<p>To generate a patch, run the <code>diff</code> program (from GNU Diffutils,
<code>v2gnu/dif272b.zip</code>) on the old and the new version
of a source file.  For example:

<pre> diff -c src/libc/dos/dos/int86.old src/libc/dos/dos/int86.c &gt;int86.dif
</pre>

<p>The file <code>int86.dif</code> created this way should be sent to the
maintainer, with a short description of the problem it solves.  It is a
good idea to run the patch file through <code>DTOU</code> (a utility which
comes with DJGPP and converts DOS-style CR-LF pairs into Unix-style
newlines), since this makes the patch work on Unix as well, in case the
maintainer of the package in question does that on Unix.  (The DJGPP
port of GNU <code>patch</code> accept both Unix-style and DOS-style patch
files.)

<p>Observing the following guidelines when creating the patch will make
your patches easy to apply:

<ul>
<li>Always use the <code>-c</code> switch to <code>diff</code>, and <strong>never</strong> use
<code>-c</code> with an argument that is less than 3 (for example, do
<em>not</em> use <code>-c2</code>).

<li>Invoke <code>diff</code> from the root of the DJGPP installation, i.e. from
the directory where you keep the <code>DJGPP.ENV</code> file, and specify the
files being compared with their pathnames relative to that directory. 
This allows to concatenate related patches to several files, and apply
the combined patch in a single run of the <code>patch</code> utility.

<li>Always use <em>forward</em> slashes in pathnames.  Backslashes will work
on DOS/Windows, but some packages are maintained on Unix machines, where
<code>patch</code> doesn't understand backslashes.  In particular, DJ Delorie
maintains DJGPP on a Unix box.

<li>It is best to let the new version of the file have the exact pathname of
the file, and rename the old to some other name like <code>foo.old</code> or
<code>foo.bak</code>; see the example above.

<li>Do <strong>not</strong> put together (on the same patch file) several unrelated
patches for different problems: the maintainer might decide to apply
only some of them, and could become confused which parts of the patch
fix what problems.  Correct one problem at a time and then make a patch
file for that problem alone; then correct another problem and generate a
patch for that one; etc.

<li>When you change the sources, try to preserve the programming style,
including indentation, of the original.  In particular, DJ Delorie
requests that the sources included in the <code>djlsrNNN.zip</code>
distribution follow his distinct style (that style is quite obvious from
the sources, but if you are unsure, ask DJ).

<li>You should <strong>never</strong> use any switches that let <code>diff</code> ignore
whitespace, like <code>-b</code> or <code>-w</code>.  In most cases, patches
generated with these switches will fail to apply. 
</ul>

<p>In addition, it would be mighty nice if every change in functionality
were accompanied by a suitable change in the relevant docs (e.g., for a
patch to a library function, edit the corresponding <code>.txh</code> file
with its docs), although you are under no obligation to do that.

<p><hr>
[an error occurred while processing this directive]