<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lib.gnustep.bugs">
    <title>gmane.comp.lib.gnustep.bugs</title>
    <link>http://blog.gmane.org/gmane.comp.lib.gnustep.bugs</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14285"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14284"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14283"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14282"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14281"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14280"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14279"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14278"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14277"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14276"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14275"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14274"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14273"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14272"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14271"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14270"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14269"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14268"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14267"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14266"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14285">
    <title>[bug #38955] NSURLConnection does not release its delegate when itshould</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14285</link>
    <description>&lt;pre&gt;Update of bug #38955 (project gnustep):

                  Status:                    None =&amp;gt; Fixed                  
             Open/Closed:                    Open =&amp;gt; In Test                

    _______________________________________________________

Follow-up Comment #1:

Thanks ... I think I fixed thjs in svn trunk ... please let me know.

    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38955&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Richard Frith-Macdonald</dc:creator>
    <dc:date>2013-05-24T14:35:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14284">
    <title>[bug #38981] NSMessagePortNameServer initialize method doesn't removeobsolete name references</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14284</link>
    <description>&lt;pre&gt;Update of bug #38981 (project gnustep):

                  Status:                    None =&amp;gt; Fixed                  
             Open/Closed:                    Open =&amp;gt; In Test                

    _______________________________________________________

Follow-up Comment #1:

Thanks, this should be fixed in trunk now ... needs some testing though.

    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38981&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Richard Frith-Macdonald</dc:creator>
    <dc:date>2013-05-24T14:34:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14283">
    <title>Re: GNUstep</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14283</link>
    <description>&lt;pre&gt;
On May 20, 2013, at 4:36 PM, Jiří Boldyš wrote:



Hello Jiri,

GNUstep does not work on Cygwin.  If you'd like to use GNUstep on Windows, we recommend the MinGW installer:

http://www.gnustep.org/experience/Windows.html

_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Adam Fedor</dc:creator>
    <dc:date>2013-05-21T14:21:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14282">
    <title>GNUstep</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14282</link>
    <description>&lt;pre&gt;Hi,
I am trying to install GNUstep and I am getting errors - logs are 
attached. Thanks for help.
Jiri
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Jiří Boldyš</dc:creator>
    <dc:date>2013-05-20T22:36:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14281">
    <title>Re: Need Help</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14281</link>
    <description>&lt;pre&gt;2013/5/16, ganesh jaiswal &amp;lt;ganesh.jn&amp;lt; at &amp;gt;gmail.com&amp;gt;:

gnustep-startup contains old gnustep packages. In the new packages,
by default, gnustep isn't installed in /usr/GNUstep. I don't remember
exactly where is this installed. But you can check the file
/etc/GNUstep/GNUstep.conf where are listed all the paths used by
GNUstep.

Regards.
&lt;/pre&gt;</description>
    <dc:creator>German Arias</dc:creator>
    <dc:date>2013-05-17T06:05:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14280">
    <title>[bug #38981] NSMessagePortNameServer initialize method doesn't removeobsolete name references</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14280</link>
    <description>&lt;pre&gt;URL:
  &amp;lt;http://savannah.gnu.org/bugs/?38981&amp;gt;

                 Summary: NSMessagePortNameServer initialize method doesn't
remove obsolete name references
                 Project: GNUstep
            Submitted by: msilvax28
            Submitted on: Mon 13 May 2013 09:08:51 PM GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

The logic in the +initialize method has logic that tries to remove old names.
It tries to remove names assigned to the current pid and tries to see if other
pids that have names are now dead.

The logic as  implemented removes no names, as it assumes the beginning of the
first line of the name file is the PID (with a . suffix).

However, the name files have this format:
&amp;lt;path to 'port' in file system&amp;gt;\n
&amp;lt;owner pid&amp;gt;\n

for example:
/tmp/GNUstepSecure1000/NSMessagePort/ports/10280.4
10280


I have code that I think fixes it, but I don't know enough about GNUstep to be
sure.





    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38981&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Michael Silva</dc:creator>
    <dc:date>2013-05-13T21:08:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14279">
    <title>[bug #38980] NSConnection can cause thread deadlock</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14279</link>
    <description>&lt;pre&gt;URL:
  &amp;lt;http://savannah.gnu.org/bugs/?38980&amp;gt;

                 Summary: NSConnection can cause thread deadlock
                 Project: GNUstep
            Submitted by: msilvax28
            Submitted on: Mon 13 May 2013 04:59:35 PM GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

There are cases in NSConnection when the use of NSRecursiveLocks between
objects can lead to 2 threads deadlocking.

The case I have seen is in gnustep-base v1.24.4.

The NSConnection method locateLocalTarget: locks the following objects in this
order

IrefGate for self

connection_table_gate

IRefGate for another NSConnection


In addition, the invalidate method locks objects in this order

IrefGate

connection_table_gate


I have seen 1 lockup scenario, and fear for another occuring.

Scenario:

NSConnection 'A' has its locateLocalTarget: methods called.  It locks the
local IrefGate and proceeds into the method.  Later in the method it locks
connection_table_gate and begins to scan the members of the connection_table.

Another NSConnection 'B' has invalidate called on another thread.  It locks
the local IrefGate and proceeds into the method.  It later attempts to lock
connection_table_gate but cannot as the thread running NSConnection 'A' has
it.  The thread blocks.

Back on the thread for NSConnection 'A', while enumerating connection_table it
attempts to lock NSConnection 'B' IrefGate.  It cannot, because the thread
running NSConnection 'B' has it.  So it locks.

The threads running NSConnections A and B are now deadlocked.


I am also concerned that the same deadlock can happen if both Connection A and
B enter locateLocalTarget at the same time where one connection gets its local
IrefGate and connection_table_gate and the other gets only its local
IRefGate.

I don't have enough context on the software to recommend a solution, although
I have 'tinkered' with something that seems to help (still testing).

For information, in my test application it takes about 8-12 hours of
continuous run before this condition occurs.







    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38980&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Michael Silva</dc:creator>
    <dc:date>2013-05-13T16:59:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14278">
    <title>[bug #38955] NSURLConnection does not release its delegate when itshould</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14278</link>
    <description>&lt;pre&gt;URL:
  &amp;lt;http://savannah.gnu.org/bugs/?38955&amp;gt;

                 Summary: NSURLConnection does not release its delegate when
it should
                 Project: GNUstep
            Submitted by: cpulsford
            Submitted on: Thu 09 May 2013 10:15:23 PM GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I am running on an Intel NUC running debian wheezy, with hand built gnustep
1.24. My GCC is version 4.7.2.

This is sort of a corollary to this bug:
https://savannah.gnu.org/bugs/?func=detailitem&amp;amp;item_id=35686

I have written a wrapper around NSURLConnection called RPMHTTPConnection. In
the attached test program, I alloc/init an RPMHTTPConnection, send a request,
receive a callback, and then release the RPMHTTPConnection instance. However,
-dealloc is never called in my RPMHTTPConnection class and I suspect that the
underlying NSURLConnection is not releasing its delegate after the request
finishes. If I am more eager about releasing the NSURLConnection, like
releasing it in the method where RPMHTTPConnection calls its own delegate, the
dealloc is called as I would expect. 

Today, May 9th 2013, I checked out the latest gnustep and I do not see
_delegate being released after the connection finished or fails.

When I run the attached program I get this output:

NSURLConnectionBug[16514] got response from instance: 0x9b19e74, data length:
44074

When I run the equivalent program on my Mac I get this output:

NSURLConnectionBug[9650] got response from instance: 0x9d8e22c, data length:
44074
NSURLConnectionBug[9650] deallocing instance: 0x9d8e22c



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 09 May 2013 10:15:23 PM GMT  Name: NSURLConnectionBug.zip  Size:
47kB   By: cpulsford

&amp;lt;http://savannah.gnu.org/bugs/download.php?file_id=28056&amp;gt;
-------------------------------------------------------
Date: Thu 09 May 2013 10:15:23 PM GMT  Name: RPMHTTPConnection.m  Size: 7kB  
By: cpulsford

&amp;lt;http://savannah.gnu.org/bugs/download.php?file_id=28057&amp;gt;

    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38955&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Cameron Pulsford</dc:creator>
    <dc:date>2013-05-09T22:15:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14277">
    <title>Re: NSFileManager -fileExistsAtPath: exception</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14277</link>
    <description>&lt;pre&gt;
On 7 May 2013, at 21:15, Cameron Pulsford &amp;lt;cpulsfor&amp;lt; at &amp;gt;me.com&amp;gt; wrote:


There should be no need ... the string is automatically converted to the file system encoding (the same thing as the default C-string encoding).
The problem here seems to be that your system is using the default encoding (latin1) and presumably your system is actually using a utf-8 based encoding.

Now, the default encoding should be automatically inferred from your operating system's nl_langinfo() function ... but may be set/overridden with the GNUSTEP_STRING_ENCODING environment variable.
So you could try setting the environment variable to the encoding you want to use.

Better still, you could run your code under gdb and set a breakpoint in the GSPrivateDefaultCStringEncoding() function (base/Source/Additions/Unicode.m) and step through and see if you can figure out why the automatic selection of encoding is not working (so we can improve that).
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Richard Frith-Macdonald</dc:creator>
    <dc:date>2013-05-08T06:37:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14276">
    <title>Re: GNUstep.h doesn't compile in C++11</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14276</link>
    <description>&lt;pre&gt;
On 7 May 2013, at 22:45, Kal &amp;lt;b17c0de&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


We would need to know what the trivial fix is ... presumably there's some problem including the system headers, since the compiler seems to think that PRIuPTR is an identifier, which it is not (it's a standard preprocessor constant which should have been replaced by a literal string before the compiler sees it).

Is that a system specific issue?  Do we need to define some other constant before including headers etc?
&lt;/pre&gt;</description>
    <dc:creator>Richard Frith-Macdonald</dc:creator>
    <dc:date>2013-05-08T06:42:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14275">
    <title>[bug #38933] [Thematic] copyright info support</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14275</link>
    <description>&lt;pre&gt;URL:
  &amp;lt;http://savannah.gnu.org/bugs/?38933&amp;gt;

                 Summary: [Thematic] copyright info support
                 Project: GNUstep
            Submitted by: rmottola
            Submitted on: Wed 08 May 2013 07:54:49 AM GMT
                Category: Application
                Severity: 2 - Minor
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Among the theme information (version, Details...) Thematic should add a line
for copyright/license information, like a regular project.

This is useful for redistribution.




    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38933&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Riccardo mottola</dc:creator>
    <dc:date>2013-05-08T07:54:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14274">
    <title>Re: NSFileManager -fileExistsAtPath: exception</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14274</link>
    <description>&lt;pre&gt;I think the problem here is that GNUstep has the impression that your file system is using Latin1, where it seems to be using UTF8. 

Fred

On the road

Am 07.05.2013 um 22:15 schrieb Cameron Pulsford &amp;lt;cpulsfor&amp;lt; at &amp;gt;me.com&amp;gt;:


_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Fred Kiefer</dc:creator>
    <dc:date>2013-05-08T07:22:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14273">
    <title>GNUstep.h doesn't compile in C++11</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14273</link>
    <description>&lt;pre&gt;Hi,
GNUstep.h doesn't compile with clang in C++11 mode. I get the following
errors:

/opt/GNUstep/Local/Library/Headers/GNUstepBase/GNUstep.h:347:19: error:
invalid suffix on literal; C++11 requires a space between literal and
identifier [-Wreserved-user-defined-literal]
      PRIuPTR", %"PRIuPTR" } extends beyond size (%"PRIuPTR")", \
                  ^
 
/opt/GNUstep/Local/Library/Headers/GNUstepBase/GNUstep.h:347:53: error:
invalid suffix on literal; C++11 requires a space between literal and
identifier [-Wreserved-user-defined-literal]
      PRIuPTR", %"PRIuPTR" } extends beyond size (%"PRIuPTR")", \
                                                    ^
 
/opt/GNUstep/Local/Library/Headers/GNUstepBase/GNUstep.h:356:30: error:
invalid suffix on literal; C++11 requires a space between literal and
identifier [-Wreserved-user-defined-literal]
    format: &amp;lt; at &amp;gt;"in %s, index %"PRIuPTR" is out of range", \

Can someone commit the trivial fix for this?

Thanks!
Kal
&lt;/pre&gt;</description>
    <dc:creator>Kal</dc:creator>
    <dc:date>2013-05-07T21:45:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14272">
    <title>NSFileManager -fileExistsAtPath: exception</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14272</link>
    <description>&lt;pre&gt;I am using debian wheezy with hand built gnustep 1.24 and the gcc 4.7.2 objc runtime.

I am getting an exception from calling [[NSFileManager defaultManager] fileExistsAtPath:] with the following two arguments and presumably others:

&amp;lt; at &amp;gt;"/home/user/GNUstep/Library/ApplicationSupport/Foo/mediaServer/Jeff Hamilton Trio-NS/J.Hamｉlton/Beatles.png"
&amp;lt; at &amp;gt;"/home/user/GNUstep/Library/ApplicationSupport/Foo/mediaServer/Brad White &amp;amp; Pierre Grill-Winter’s Journey.png"

Here are those strings again converted with CFStringTransform to include the unicode special character names:

&amp;lt; at &amp;gt;"/home/user/GNUstep/Library/ApplicationSupport/Foo/mediaServer/Jeff Hamilton Trio-NS/J.Ham\N{FULLWIDTH LATIN SMALL LETTER I}lton/Beatles.png"
&amp;lt; at &amp;gt;"/home/user/GNUstep/Library/ApplicationSupport/Foo/mediaServer/Brad White &amp;amp; Pierre Grill-Winter\N{RIGHT SINGLE QUOTATION MARK}s Journey.png"

Internally, that method eventually calls [GSUnicodeString cStringUsingEncoding:NSISOLatin1StringEncoding] which raises this exception: &amp;lt;NSException: 0x83a29bc&amp;gt; NAME:NSCharacterConversionException REASON:Can't get cString from Unicode string. INFO:(null)

I do not get this crash when running the same code on a mac. Is there any way I should be sanitizing strings before I pass them to the -fileExistsAtPath: method?



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Cameron Pulsford</dc:creator>
    <dc:date>2013-05-07T20:15:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14271">
    <title>Re: GNUstep doesn't want to compile from packages in FreeBSD 9.2 x64</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14271</link>
    <description>&lt;pre&gt;I don't have a FreeBSD, so I don't know how supposedly should work it. But try with the official released packages. I think is better if you write to people who made the packages for FreeBSD. Also, I don't know if those packages are updated. Or try with the official packages of gnustep. Installing these one by one. Regards.

On 2013-05-01 20:32:48 -0600 Bartlomiej Mika &amp;lt;bmika&amp;lt; at &amp;gt;icloud.com&amp;gt; wrote:



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Germán Arias</dc:creator>
    <dc:date>2013-05-03T17:38:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14270">
    <title>GNUstep doesn't want to compile from packages in FreeBSD 9.2 x64</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14270</link>
    <description>&lt;pre&gt;Hi!

So when I run cd /usr/ports/devel/gnustep &amp;amp;&amp;amp; make install clean I get the following error:

Code:
configure: exit 1
(end of "config.log")
*** [do-configure] Error code 1

Stop in /usr/ports/lang/gnustep-base.
*** [build-depends] Error code 1

Stop in /usr/ports/devel/gnustep.
Ok, so I got into /usr/ports/lang/gnustep-base and run the whole make and install and I then get the following error:
Code:
configure: exit 1
(end of "config.log")
*** [do-configure] Error code 1

Stop in /usr/ports/lang/gnustep-base.
I'm at a loss on what to do next. Any hints? I think this is a bug….

Thanks!

_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Bartlomiej Mika</dc:creator>
    <dc:date>2013-05-02T02:32:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14269">
    <title>[bug #38859] GDL2 build failures on Apple platforms</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14269</link>
    <description>&lt;pre&gt;Follow-up Comment #2, bug #38859 (project gnustep):

Hi Matt,

thanks for the advice. Removing the EOAccess_LIBRARIES_DEPEND_UPON line is
sufficient, so the ADDITIONAL_NATIVE_LIBS settings in the preamble are
working. However, I don't know whether this would affect other platforms, so
no patch yet:

The Target_LIBRARIES_DEPEND_UPON were added in r35397, which just says "Add
flags":

2012-08-10  German A. Arias  &amp;lt;german&amp;lt; at &amp;gt;xelalug.org&amp;gt;

        * EOInterface/GNUmakefile:
        * EOAccess/GNUmakefile:
        * EOAdaptors/SQLiteAdaptor/GNUmakefile.in:
        * EOAdaptors/PostgreSQLAdaptor/config.mak.in:
        * EOControl/GNUmakefile:
        * EOModeler/GNUmakefile: Add flags to compile with new linkers.

I guess we need to ask German what "new linkers" there are, and how removing
Target_LIBRARIES_DEPEND_UPON might break them?

Thanks,
Graham.



    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38859&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Graham Lee</dc:creator>
    <dc:date>2013-05-01T09:20:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14268">
    <title>[bug #38859] GDL2 build failures on Apple platforms</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14268</link>
    <description>&lt;pre&gt;Follow-up Comment #1, bug #38859 (project gnustep):

the following entries in Makefile.preamble used to link this with the
appropriate linker command line for the platform, figuring out whats gone awry
there would be the right place to start


ADDITIONAL_NATIVE_LIBS += EOControl
ADDITIONAL_NATIVE_LIB_DIRS+=../EOControl

(apologies if this gets sent twice)

    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38859&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>matt rice</dc:creator>
    <dc:date>2013-05-01T02:17:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14267">
    <title>[bug #38859] GDL2 build failures on Apple platforms</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14267</link>
    <description>&lt;pre&gt;URL:
  &amp;lt;http://savannah.gnu.org/bugs/?38859&amp;gt;

                 Summary: GDL2 build failures on Apple platforms
                 Project: GNUstep
            Submitted by: leeg
            Submitted on: Tue 30 Apr 2013 02:32:54 PM GMT
                Category: gdl2
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hi,

I'm building GDL2 from r36452 on apple-apple-apple. The build is fine, but
linking fails because it tries to use Linux-style -lFramework instead of
Apple-style -framework Framework flags. I can patch the GNUmakefiles to solve
my problem (example below), but a patch should really support both linker
styles and I don't know how I'd do that.

Thanks,
Graham.


-EOAccess_LIBRARIES_DEPEND_UPON = -lEOControl $(OBJC_LIBS)
+EOAccess_LIBRARIES_DEPEND_UPON = -framework EOControl $(OBJC_LIBS)





    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?38859&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
&lt;/pre&gt;</description>
    <dc:creator>Graham Lee</dc:creator>
    <dc:date>2013-04-30T14:32:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14266">
    <title>[bug #35671] Wrong error from -[NSFileManagercreateDirectoryAtPath:...]</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14266</link>
    <description>&lt;pre&gt;Follow-up Comment #1, bug #35671 (project gnustep):

I don't know how precise compatibility with Mac OS X/Cocoa should be for this
bug, but the behaviour proposed in the patch doesn't match it:

'Wrong error Error Domain=NSCocoaErrorDomain Code=516 "The file “foobar”
couldn’t be saved in the folder “tmp” because a file with the same name
already exists." UserInfo=0x7f85d940ab80 {NSFilePath=/tmp/foobar,
NSUnderlyingError=0x7f85d940a9d0 "The operation couldn’t be completed. File
exists"}'

but error code 516 is not EEXIST and the error is in the Cocoa error domain.
The _underlying_ error is in NSPOSIXErrorDomain and has code 17 (EEXIST). The
matching Foundation error (from Foundation/FoundationErrors.h) is this:

    NSFileWriteFileExistsError NS_ENUM_AVAILABLE(10_7, 5_0) = 516,          //
Write error (file exists)

which is what NSFileManager returns in Foundation. I think it'd be reasonable
for GNUstep-base to follow that example.


    _______________________________________________________

Reply to this item at:

  &amp;lt;http://savannah.gnu.org/bugs/?35671&amp;gt;

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-gnustep mailing list
Bug-gnustep&amp;lt; at &amp;gt;gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
&lt;/pre&gt;</description>
    <dc:creator>Graham Lee</dc:creator>
    <dc:date>2013-04-29T15:51:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14265">
    <title>Re: Need Help</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.gnustep.bugs/14265</link>
    <description>&lt;pre&gt;On 2013-04-29 00:02:22 -0600 ganesh jaiswal &amp;lt;ganesh.jn&amp;lt; at &amp;gt;gmail.com&amp;gt; 
wrote:


 From where downloaded you these packages? Download these separately 
from here:

http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-make-2.6.4.tar.gz
http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-base-1.24.4.tar.gz
http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-gui-0.23.1.tar.gz
http://ftpmain.gnustep.org/pub/gnustep/core/gnustep-back-0.23.0.tar.gz

And install them one by one. Hope this help.
&lt;/pre&gt;</description>
    <dc:creator>Germán Arias</dc:creator>
    <dc:date>2013-04-29T06:59:34</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lib.gnustep.bugs">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lib.gnustep.bugs</link>
  </textinput>
</rdf:RDF>
