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
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
