Re: MinGW Build

["muppet" <scott asofyet org>]

Timm Murray said:
> On Wednesday 30 November 2005 01:42 pm, muppet wrote:
> ----
> Can't load 'e:/perl-5.8.7/site/lib/auto/Glib/Glib.dll' for module Glib:
> load_file:Attempt to access invalid address at
> e:/perl-5.8.7/lib/DynaLoader.pm line 230.
> ----
>
> The Glib module passed its tests, and 'perl -MGlib -e ""' works, so I don't
> think the Glib module is the problem.  The issue seems to be this line (which
> is inside a string eval):
>
> ----
> "use Glib '$build_reqs{'perl-Glib'}';"
> ----
>
> Putting a "use Glib;" at the top of the module makes the problem go away.

To what does that string evaluate?  It should be something simple like "use
Glib '1.100';" (or whatever the actual required version is)...  is it turning
up empty?


> The straight 'make' program has not worked for me when building Perl itself or
> any modules.  The 'dmake' program must be used instead.  However, with the
> straight Makefile, dmake gives the following error:
>
> ----
> dmake:  makefile:  line 19:  Error: -- Input line too long, increase
> MAXLINELENGTH

Undoubtedly this is the line that looks like

  perl -MFoo bar '[ qq[File1.o] qq[File2.o] qq[File3.o] ... ]'

In the past a workaround for this has been to hand-edit the makefile to use a
more compact syntax, e.g.

  perl -MFoo bar '[qw(File1.o File2.o File3.o ... )]'

as this command runs up against command line length limits for cmd.exe or
command.com or whatever it is.  This solution doesn't scale, and your
MAXLINELENGTH is better for your situation, but i don't know what else to do
for the normal NMake situation.


> This gets rid of most (but not quite all) the linking errors.  The options
> MUST go after the files being linked, or else they seem to be ignored (I've
> noted this behavior while building SDL_perl, too).

This is a known thing about how linkers work, not specific to GCC.  The actual
reason is complicated and specific to implementations, and any attempt at
explanation is bound to be incomplete, inaccurate, and misleading.  The
working understanding of "the thing that provides a symbol must occur after
the thing that uses the symbol" has served me without fail.


> As noted in the reply above, the Glib.dll module built for the Glib Perl
> module must be added to the link command.  Putting in
> "E:/perl-5.8.7/site/lib/auto/Glib/Glib.dll" after the linked files (but
> before the library options noted above) fixes all errors.  I then ran 'dmake'
> again to finish off the make process.

A safer bet for that would be after all of the *.o files and before all of the
-l options.


> Next comes 'dmake test'.  This fails with a popup that says "This application
> has failed to start because dll.exp.dll was not found. Re-installing the
> application may fix this problem."  I'm not sure where this dll.exp.dll is
> supposed to come from.  Google seems silent on the matter.

That sounds suspiciously like a bad filename.  Are all the command-line
options sane?


-- 
muppet <scott at asofyet dot org>