In general, compiling modules with a compiler other than the one
used to build Perl is not supported.

When you build Perl, a great deal of information about your
operating system, compiler, include files, and run-time libraries
is analysed.  The results of this analysis and some personal
preferences about how you want Perl built end up in Config.pm
and a bunch of C include files that end up someplace like
lib/core/*.h.

Changing Config.pm and lib/core/*.h to match what they would have
been had you used a different compiler to build Perl can be quite
a challenge and can also result in modules being built that are
not compatible with your copy of Perl.

There are many ordered pairs of combinations of systems,
compilers, and Perl options where modules built under one set
will work with Perls built on the other.  While it can be easy to
determine that a given pair does *not* belong to this set, trying
to show that a given pair *does* belong to this set can be a
daunting task.  It may appear to work for a while and then you
start running into strange errors.

) Building perl with gcc on Irix is troublesome, I have to patch gcc to do
) that (has to do with integer sizes in n32), as someone suggested.

This sounds like the type of thing that would break a Perl module
built with an unpatched version of gcc anyway.  It sounds like
you'll end up with incompatible structs between Perl and the module.

) Number found where operator expected at (eval 103) line 1, near "*(138"
) (Missing operator before 138?)