For starters some background info:<br><br><a href="http://www.mono-project.com/I18nGettext">http://www.mono-project.com/I18nGettext</a>  -- Show how to use GetText# which exposes an Gnu.GetText namespace and thus presumably should package such a Gnu.GetText.dll as discussed in this thread.<br>
<br>Perusing the released sources of gettext (gettext-0.17.tar.gz), I&#39;ve found that GNU.Gettext.dll is built from it (excerpt from gettext-0.17\gettext-runtime\intl-csharp\Makefile.am):<br><br>GNU.Gettext.dll: intl.cs<br>
    $(CSHARPCOMP) $(CSHARPCOMPFLAGS) -o $@ $(srcdir)/intl.cs<br><br>So it is not part of Mono, and probably it is just some byproduct of some native packages dependencies, as you guessed.<br><br>More relevant to this discussion is that the license from intl.cs is GPL 2.0, without mention of a linking exclusion clause<br>
<br> * This program is free software; you can redistribute it and/or modify it<br> * under the terms of the GNU Library General Public License as published<br> * by the Free Software Foundation; either version 2, or (at your option)<br>
 * any later version.<br><br>So your app should be GPL-licensed to comply, which is an even worse situation for you. <br>I recommend you to implement your own catalog reading code, reading from the documentation (sic) of the .po format, and then if you could open source it under a more sensible license such as MIT/BSD or at least MS-PL it would be very nice.<br>
<br>Using Mono.Posix will leave you with a native lib dependency with a GPL+Linking exclusion license, which is probably not that much desirable, but at least Mono.Posix you can either sign it yourself or just copy-paste the small wrapper class (Mono.Unix.Catalog) in your own lib as it is MIT/BSD licensed.<br>
<br>Hope it helps,<br><br clear="all">Rafael &quot;Monoman&quot; Teixeira<br>---------------------------------------<br>&quot;To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it.&quot; <br>
Osho <br>
<br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 7:44 AM, Jacques Beaurain <span dir="ltr">&lt;<a href="mailto:jacques.beaurain@gmail.com">jacques.beaurain@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
Thanks for the response but this does not solve my issue...<br>
<div class="im"><br>
On Tue, Mar 2, 2010 at 4:12 PM, Jonathan Pryor &lt;<a href="mailto:jonpryor@vt.edu">jonpryor@vt.edu</a>&gt; wrote:<br>
&gt; On Tue, 2010-03-02 at 12:21 -0500, Jacques Beaurain wrote:<br>
&gt;&gt; ...  The issue that we face is<br>
&gt;&gt; that this assembly is not signed and we need to be able to place the<br>
&gt;&gt; assembly in the GAC of Microsoft Windows systems. What is the<br>
&gt;&gt; recommended way to handle this situation?<br>
&gt;&gt;<br>
&gt;&gt; In particular we are interested in the GNU.Gettext.dll assembly.<br>
&gt;<br>
&gt; Er, what?  I don&#39;t see this assembly in my GAC (both the distro-provided<br>
&gt; and my trunk installation), nor do I see a GNU.Gettext.dll assembly in<br>
&gt; my source tree.  Where are you seeing this assembly?<br>
&gt;<br>
<br>
</div>It is in the lib tree of the current Mono release build. My guess is<br>
that the build process builds it by pulling in the gettext sources.<br>
<div class="im"><br>
&gt; To answer the original question, the answer is: don&#39;t.  For the love of<br>
&gt; all that is good and holy, don&#39;t strong-name an assembly that isn&#39;t<br>
&gt; strong-named and install it into the GAC.<br>
&gt;<br>
&gt; Strong-naming is an indication that the API won&#39;t change in an<br>
&gt; incompatible manner, possibly ever.  Upstream likely won&#39;t even know you<br>
&gt; did this, will eventually break API, and cause all manner of pain.<br>
&gt;<br>
&gt; (Case in point: Mono has two separate copies of SharpZipLib because they<br>
&gt; changed their API in an incompatible manner.  I don&#39;t know who<br>
&gt; strong-named it -- i.e. was it it Mono being bad, or were they screwing<br>
&gt; things up -- but it&#39;s not a good situation to be in.)<br>
&gt;<br>
&gt; YOU have sources and a compiler toolchain.  If you need a strong-named<br>
&gt; assembly, fold it into your own assemblies and strong name *those*, so<br>
&gt; that responsibility for maintaining API compatibility is clear.<br>
<br>
</div>This is exactly the issue, the assemblies that need to use it is<br>
strong named already and can only reference strong named assemblies. I<br>
would love to fold the functionality into  my own assemblies but are<br>
not allowed to do so under the terms of the LGPL. Anyway my solution<br>
is gravitating to not using this assembly at all and using interop to<br>
the unmanaged gettext libraries instead which should allow us to abide<br>
by the LGPL terms.<br>
<br>
&gt;<br>
&gt;  - Jon<br>
&gt;<br>
&gt;<br>
&gt;<br>
<font color="#888888"><br>
Jacques<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</div></div></blockquote></div><br>