On Tue, 2007-03-13 at 14:25 -0600, Eric Morgan wrote: > 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.
That was my guess ;-) Mono-devel-list is the best one for such cases. > Test cases are hard to produce, I 100% agree and this is why it's important for people to provide them. Otherwise our bug fixing speed would drop significantly (to write test cases) and a lot of bug would be closed because we wouldn't be able to duplicate the (existing) issue (e.g. lack of important details, environment related issues...). A lot of time the test cases also provides the basis for new unit tests which, in turns, diminish the likelihood that the bug will return to haunt you (and us ;-) > because our codebase is rather large and tangled. It's also > commercial .NET software, so I can't just upload the source code > somewhere... well we do have a bug preference for *small* test cases ;-) > 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. ah, it's not managed code :| and probably not (much) mono-aware so it consider mono as the "root" executable. Maybe (untried) you can consider having a wrapper executable to call the runtime ? (instead of your own mono ?) > 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. If that's an install-time only issue then you should require someone with su privileges to install the software. If you need to write at every execution time then it's not an option. > Is this a HUGE security issue or something? That depends on how you fix it. Having a local mono install isn't a security issue - but modifying /usr/bin directory permissions could be. > > 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. Keep in mind that libgdiplus was only an example. The kind of problems likely to occur from this don't looks like your current issue. > 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? There are a lot of options to change the default behavior and to make sure they are ok (i.e. test them). See "man mono" for a list of options. Many of them are also documented on the web site (e.g. for dealing with multiple mono installations). > 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. :/ Good news, it's not your fault ;-) Now it's time to fill a bug report :| > Eric Morgan > > > > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
