[Mono-list] [mono-list] Merging compiled SVN with installed version.

[Eric Morgan]

Sabastien,

I think the reason I submitted this to mono-list, is because my main
question was with the compilation of mono, not to the bugs I was
experiencing.  I think the bugs are from my custom installation, and I
wanted to make sure I was doing these things right.


Test cases are hard to produce, because our codebase is rather large and
tangled.  It's also commercial .NET software, so I can't just upload the
source code somewhere...  It may take me a while, because there's so much
going on in our code right now.  I'll get back on this.


>   Additionally, for some of our code, we need to write to the

> > executing directory, which is actually mono...
>
> Well you shouldn't be writing there ;-) and I'm not sure how you got
> there (bad scripts ?). You may have to write to the *current* directory
> (the one of the .exe you're running) and this one may (or not) have the
> required permissions to allow this.


I can tell you exactly how I'm getting there.  Our licensing company
requires that a .xml file be present in the same directory as the executing
application at the time their API functions are called.  After many hours of
debugging, I determined that the executing application was actually Mono
instead of our .exe.  I have no control over that bit of API code, as we're
P/Invoking into it.  The linux libraries do, however, work fine.  I even
contacted them and they told us "sorry, no other option than that .xml file
in the same directory".  Without that licensing, our software won't run, so
I think it's major enough that we request write permission to those
directories.

Is this a HUGE security issue or something?


> Anyway, we're bundling our own version of mono that's the generic x86
> > linux distribution.  We've done a local install, and we have many
> > scripts to run our program so it uses the supplied version of mono and
> > configurations.  The problem is, there's some fixes in SVN we'd really
> > like to have, and we don't know how long before another official
> > release will be.  So, I compiled the SVN code with a prefix of our
> > local installation, and just had it make install into that directory.
> > Everything seemed fine at first, but I started noticing some issues
> > with our MDI relating to X11.  My question is, do I need to link
> > everything differently, so it's using the dependencies in our local
> > installation instead of the ones installed by my distribution?
>
> Maybe not everything, but yes some things. For example(*) you must
> ensure that the libgdiplus.so being loaded is the one that match the
> System.Drawing.dll you use (on which System.Windows.Forms.dll depends).
> If not then you may experience bugs, crash, rain, lost of sleep...



I will double check which libgdiplus.so it's trying to load, but I compile
libgdiplus with mono, and both binaries are installed in the prefix.   I'm
mostly worried about stuff like libpng, libungif, libpangosharpglue,
libncurses, and other dependency packages.  I don't want Mono to be looking
for these already installed by the distro, and when I distribute the
software, it errors out saying it can't find them.  Will mono search the
MONO_PREFIX/lib/ folder at runtime if it can't find the libraries
elsewhere?  Will it check that first?


> The best way to find out is to try your code on a fully synchronized
> mono version, e.g. SVN HEAD (both mono, mcs and libgdiplus). If it works
> then it's a result of your customized version, if not it's probably a
> regression (and a new bug report should be opened to ensure this is
> fixed prior to the next official release).



Just tried with my synchronized version of SVN HEAD (r74177), and it
performs the exact same behavior as I'm describing.  :/

Eric Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20070313/09b948b8/attachment.html