[Mono-winforms-list] swf

Paul paul@all-the-johnsons.co.uk
Thu, 28 Oct 2004 01:03:49 +0100


--=-XRR75Z+usVWGxpmGvttg
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

> So that solves the problem, but the experience of figuring it out got
> me to thinking.  When dlopen failed, mono didnt distinguish between a
> missing DLL and one that couldnt be opened for other reasons.  It kept
> trying the lib in other places (a few of which were symlinks, so it
> actually hit the same dlopen failure multiple times), then eventually
> threw DllNotFoundException. =20

The DllNotFoundException doesn't mean that it can't find the dll. What
it means is it can't find the method the program is requesting.

> A related question: if mono tries to load a library that really does
> exist, but dlopen/LoadLibrary fails, should mono really continue to
> try additional places? =20

=46rom rom my understanding, mono will try to load from LD_LIBRARY_PATH -
so /usr/local/lib first, /usr/lib next and finally (not that the libs
should ever be in it) /lib.

> Failure to load a library that exists is an entirely different problem
> than failure to find a library when doing a multiple-path library
> search.

Yes, but it's not a mono problem. If you've compiled *any* application
and set it to run in say /opt/somewhere/or/other with the libs
in /opt/somewhere/or/libs, then unless you have deliberately told via
the ./autogen.sh script where the libs are going to be, then how on
earth is any application going to know where it's library files are? It
will search LD_LIBRARY_PATH, if the file is not there, tough. Game over.

> A related observation: the same problem appears if you try to load an
> SWF form when X isn't started.

What would you expect? MWF (Managed.Windows.Forms - the non Wine
version) writes to an inbetween layer which addresses the windowing
system. No windowing system, no display.

> The failure gets reported as a NullReferenceException, but if you turn
> on the lib loader trace output, you'll see that it's caused by a
> failure to load libX11.so.

Which isn't loaded as X isn't running!

> It seems like there ought to be _some_ way, even if non-standard, to
> get that very important information back out to the user.  Most apps
> say something like "Cannot connect to display..." when that happens.

Remember though, Mono isn't just for Linux - it's for just about any
platform out there. For a system using X, fair enough. But if you had
something like which does weird things to connect to the display, the
above error would be useless.

> I'll be happy to try my hand at making any modifications that come
> about from this discussion, but maybe I'm just off in left field and
> things should stay exactly as they are anyway.  Any takers?

Error codes are tricky and the other things you've raised (and I've
replied to) aren't really mono issues.

TTFN

Paul
--=20
"Trust me, I know what I'm doing" - Det. Sledgehammer

--=-XRR75Z+usVWGxpmGvttg
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBgDdlusSVe5EZv3wRAh9pAJ4xgVBdllbNB8Pfs8vN8hUQ0N2eRQCgpNJg
EpUyhPhSeR4JyFHsOcFHwJ0=
=4O7G
-----END PGP SIGNATURE-----

--=-XRR75Z+usVWGxpmGvttg--