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

[Sebastien Pouliot]

Hello Eric,

a few (very partial) answers...

On Tue, 2007-03-13 at 13:12 -0600, Eric Morgan wrote:
> Hey all,
> 
> (sorry, long)
> 
> So, our software is using mono so we can offer our C# code on linux.
> We've had lots of issues with mono installations, as they vary from
> customer to customer.  Additionally, we've found that people that
> install mono as root, or in a non local prefix (like.. /usr/) there
> ends up being weird permission errors.

Sorry there's not enough details to help. It doesn't sounds like a
common (known) bug so you better fill one at bugzilla.ximian.com with
instructions on how to repeat 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.

> 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...

(*) that's just one example

> Is there some configuration I'm doing wrong?  

Maybe, maybe not (can't be sure without a test case).

While cherry-picking patches is possible it also has a lot of potential
pitfalls. You better have a very good understanding of the software and
it's options (or wait for the next official release).

> Is this an inherantly bad idea?  

IMO yes. At best you'll be getting a "unique" configuration (with unique
bugs). At worse it won't work and no one will be able to duplicate it
(i.e. help you).

> Or is there a regression issue with MDI and X11 that I'm bumping
> into? 

Maybe some people noticed something similar? but I didn't.

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).

> First, if we have a window open and we open a second window, some of
> the control don't render properly on the second window.  The window
> now on the foreground just won't draw properly and you can actually
> see part of the previous window drawn on the top window, which stays
> drawn even if you move or resize the top window .  Sometimes it can
> recieve events and operate OK, but the more we work in that window the
> more things break down.  Different controls start to draw strange,
> refreshing doesn't work, there's stuff that doesn't even GET drawn.
> The exact same window, if I open it first, works perfectly.  It's only
> when *any* window is opened as a second MDI document.  Switching
> windows works fine. 
> 
> Second, when I close that top window, I get utterly spammed with X11
> errors.  I truncated the stacktrace, I can send if you want, but it's
> a pretty generic one.  The error is:
> X11 Error encountered:
>  Error: BadWindow (invalid Window parameter) 
>  Request:     7 (X_ReparentWindow)
>  Resource ID: 0x3C05C40
>  Serial:      189634
>  Hwnd:        Hwnd, Mapped:True ClientWindow:0x3C05C40,
> WholeWindow:0x3C05C3F, Parent:[Hwnd, Mapped:True
> ClientWindow:0x3C05C32, WholeWindow:0x3C05C31, Parent:[Hwnd,
> Mapped:True ClientWindow:0x3C05C30, WholeWindow:0x3C05C2F,
> Parent:[Hwnd, Mapped:True ClientWindow:0x3C05C2A,
> WholeWindow:0x3C05C29, Parent:[Hwnd, Mapped:True
> ClientWindow:0x3C05C28, WholeWindow:0x3C05C27, Parent:[Hwnd,
> Mapped:True ClientWindow:0x3C05C24, WholeWindow:0x3C05C23,
> Parent:[Hwnd, Mapped:True ClientWindow:0x3C05C20,
> WholeWindow:0x3C05C1F, Parent:[Hwnd, Mapped:True
> ClientWindow:0x3C05C1E, WholeWindow:0x3C05C1D, Parent:[Hwnd,
> Mapped:True ClientWindow:0x3C05BF2, WholeWindow:0x3C05BF1,
> Parent:[<null>]]]]]]]]]
>  Control:     System.Windows.Forms.GroupBox, Text: Diagnostic
>   (STACKTRACE)
> 
> 
> 
> Any Advice?  

In doubt open a new bug report with a, as small as possible, test case
with source code.

> Thanks for the help and sorry about the long email.  

You should send SWF-related questions to mono-winforms-list instead of
mono-list or more general development questions to mono-devel-list.
http://www.mono-project.com/Mailing_Lists

> I didn't want to just submit a bug report, because it may not even be
> a bug.

Don't worry we can close such reports as NOTABUG ;-)

>   I want to double check here. 


> Eric Morgan
> Renegade Geophysics
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/