[bug #42433] [cairo] FTBFS with -Wl,--no-undefined

2014-07-24 Thread Fred Kiefer 
Update of bug #42433 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for the patch, I have committed it.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42542] [WinUX] popup / context menu get placed wrong

2014-07-24 Thread Fred Kiefer 
Update of bug #42542 (project gnustep):

Category: Backend => Libraries  

___

Follow-up Comment #1:

I changed the category to libraries as you stated in a mail that this
behaviour happens only with the theme switched on, not with the native backend
on Windows.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

2014-07-24 Thread Fred Kiefer 
Update of bug #42782 (project gnustep):

  Status: In Progress => Ready For Test 
 Open/Closed:Open => In Test

___

Follow-up Comment #15:

I think I fixed the original GSGormLoading.m bug. Could you please give this a
try?

As for the gcc 4.8.3 bug in Vindaloo I did not quite understand the
description there. Why do you think that _bounds is undefined in NSClipView
setFrame:? I would expect the super call to have set it correctly. Is there
something I am missing?



___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42778] Frameworks with different SONAME cannot coexist

2014-07-24 Thread Yavor Doganov 
Follow-up Comment #2, bug #42778 (project gnustep):

Proposed patch attached.  It makes the existence of two framework versions (in
fact, multiple framework versions) possible.  It doesn't delete the installed
framework prior to the installation of the new one and symlinks are created
directly to the versioned directory instead of the Current symlink.  Also,
since Resources are version-specific (or at least they may be) it is not
correct to create a Resources symlink pointing to Current.  Headers are also
version-specific but as there can only be one .so symlink only one set of
headers can be used at any time (the "Current" headers, so this behavior is
retained).

Tested with RSSKit/0.3, then RSSKit/0.4 installed on top of it with
INTERFACE_VERSION set to 1, then RSSKit/0.4 with VERSION bumped to 0.4.1
(simulating a new release which is ABI-compatible with 0.4).  It appears to
work:

$ ls -l /tmp/foo/usr/lib/
общо 28
drwxr-xr-x 3 yavor yavor 4096 юли 24 14:44 GNUstep
lrwxrwxrwx 1 yavor yavor   67 юли 24 15:02 libRSSKit.so ->
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   63 юли 24 14:44 libRSSKit.so.0 ->
./GNUstep/Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor   65 юли 24 14:44 libRSSKit.so.0.3 ->
./GNUstep/Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0.3
lrwxrwxrwx 1 yavor yavor   65 юли 24 14:47 libRSSKit.so.0.4 ->
./GNUstep/Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4
lrwxrwxrwx 1 yavor yavor   67 юли 24 15:02 libRSSKit.so.0.4.1 ->
./GNUstep/Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4.1
lrwxrwxrwx 1 yavor yavor   63 юли 24 15:02 libRSSKit.so.1 ->
./GNUstep/Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.1
$ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/
общо 4
lrwxrwxrwx 1 yavor yavor   24 юли 24 14:46 Headers ->
Versions/Current/Headers
lrwxrwxrwx 1 yavor yavor   31 юли 24 14:47 libRSSKit.so ->
./Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   25 юли 24 14:47 RSSKit ->
./Versions/Current/RSSKit
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:46 Versions
$ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/
общо 8
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:43 0
drwxr-xr-x 4 yavor yavor 4096 юли 24 15:00 1
lrwxrwxrwx 1 yavor yavor1 юли 24 14:46 Current -> 1


Installing in the USER domain is OK too:

$ ls -l ~/GNUstep/Library/Libraries/
общо 8
lrwxrwxrwx 1 yavor yavor 60 юли 24 15:00 libRSSKit.so ->
../Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor 56 юли 24 14:44 libRSSKit.so.0 ->
../Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor 58 юли 24 14:44 libRSSKit.so.0.3 ->
../Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0.3
lrwxrwxrwx 1 yavor yavor 58 юли 24 14:47 libRSSKit.so.0.4 ->
../Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4
lrwxrwxrwx 1 yavor yavor 60 юли 24 15:00 libRSSKit.so.0.4.1 ->
../Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4.1
lrwxrwxrwx 1 yavor yavor 56 юли 24 15:00 libRSSKit.so.1 ->
../Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.1
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/
общо 4
lrwxrwxrwx 1 yavor yavor   24 юли 24 14:46 Headers ->
Versions/Current/Headers
lrwxrwxrwx 1 yavor yavor   31 юли 24 14:47 libRSSKit.so ->
./Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   25 юли 24 14:47 RSSKit ->
./Versions/Current/RSSKit
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:46 Versions
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/Versions/
общо 8
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:43 0
drwxr-xr-x 4 yavor yavor 4096 юли 24 15:00 1
lrwxrwxrwx 1 yavor yavor1 юли 24 14:46 Current -> 1
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/Versions/0/
общо 256
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:43 Headers
lrwxrwxrwx 1 yavor yavor 14 юли 24 14:43 libRSSKit.so ->
libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor 16 юли 24 14:43 libRSSKit.so.0 ->
libRSSKit.so.0.3
-rwxr-xr-x 1 yavor yavor 246948 юли 24 14:43 libRSSKit.so.0.3
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:43 Resources
lrwxrwxrwx 1 yavor yavor 12 юли 24 14:43 RSSKit -> libRSSKit.so
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/Versions/1/
общо 504
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:46 Headers
lrwxrwxrwx 1 yavor yavor 14 юли 24 15:00 libRSSKit.so ->
libRSSKit.so.1
-rwxr-xr-x 1 yavor yavor 249584 юли 24 14:47 libRSSKit.so.0.4
-rwxr-xr-x 1 yavor yavor 249584 юли 24 15:00 libRSSKit.so.0.4.1
lrwxrwxrwx 1 yavor yavor 18 юли 24 15:00 libRSSKit.so.1 ->
libRSSKit.so.0.4.1
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:47 Resources
lrwxrwxrwx 1 yavor yavor 12 юли 24 15:00 RSSKit -> libRSSKit.so


I also checked that projects that have an internal framework (whether intended
to be public or not) and set ADDITIONAL_LIB_DIRS to something like
"-L../../Foo.framework/Versions/Current" continue to build/link without
problems.

As this is one of the most sensitive a

[bug #42782] Crash when loading a gorm file

2014-07-24 Thread Yavor Doganov 
Follow-up Comment #14, bug #42782 (project gnustep):

I was wrong, cannot reproduce with GCC 4.8.3.  Gorm opens the file just fine. 
Vindaloo crashes at -[CenteringClipView constrainScrollPoint:] which could be
a bug in Vindaloo as it opens the PDF file if I modify it to use plain
NSClipView. The backtrace shows a corrupt stack again:

Program received signal SIGSEGV, Segmentation fault.
0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xb088, 
_cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82
82 return newScrollPoint;
(gdb) bt
#0  0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xb088,

_cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82
#1  0xb0b8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Two interesting things:

* In -[GSWindowTemplate initWithCoder:] there's no _object as well but no
crash either.  The execution continues.

* -[CenteringClipView setFrame:] just calls the super class implementation,
which in turn calls [self setBoundsOrigin: [self constrainScrollPoint:
_bounds.origin]]; _bounds is undefined at this point.  This method is actually
overriden with Vindaloo's own -constrainScrollPoint: where the crash happens. 
proposedNewOrigin is optimized there, it might be just garbage and not a valid
NSPoint.

___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

2014-07-24 Thread Yavor Doganov 
Follow-up Comment #13, bug #42782 (project gnustep):

I think this should be reproducible with GCC 4.8 as well, it's the
architecture that matters.  As x86 is gradually being replaced with x86_64
it's not a big surprise that the majority of users do not encounter these
bugs.  I'll try to reproduce with older compiler versions.

___

Reply to this item at:

  

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


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

2014-07-24 Thread Fred Kiefer 
Update of bug #42782 (project gnustep):

Category:Gorm => Gui/AppKit 
 Assigned to:None => FredKiefer 

___

Follow-up Comment #12:

Thank you for digging so deep. We need to set up a way to analyze this problem
on more machines. I have a look and see whether gcc 4.9 is in some way
available for OpenSuse.

The specific issue you ran into seems to be the line in GSGormLoading.m where

_screenRect = [[_object screen] frame];

uses _object instead of obj. I hope to find time to verify and fix that later
today or at least tomorrow. The downside is that even with this fixed there
will be a next problem and then another. You shouldn't be doing all that hard
work alone.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep