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

[Sebastien Pouliot]

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  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list