[bug #22351] GDNC not starting properly on some systems.

[Yavor Doganov]

Follow-up Comment #7, bug #22351 (project gnustep):

This problem happens quite often in Debian as of Base 0.14 (which has the
--auto option by default), with many applications; users have reported such
problems on i386, powerpc and amd64.  The solution in comment #1 does not
help, unfortunately.

I've been using a modified GNUstep Base on all my machines for some time and
I can't reproduce the problem with the attached patch.  This is not a clean
solution either, since it generally slows down app startup time.

Either way, debugging this obscure problem is really hard.

(file #15064)
___

Additional Item Attachment:

File name: clean-tmpdir.diff  Size:1 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?22351

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



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

[bug #22351] GDNC not starting properly on some systems.

[Yavor Doganov]

Follow-up Comment #9, bug #22351 (project gnustep):

But this happens at a time when gdnc is either not started or is
non-functional, so it is safe to assume that no such connections exist.  Isn't
it so?  I may be totally wrong, I don't understand the code very well.

Here's how I've been able to trigger this bug, although not reliably (as I
said I cannot reproduce with my patch, whether right or wrong -- and I
certainly don't claim it's right):

1. Kill all daemons as suggested in the original submission.
2. Start an app (Ink, Preferences) that would lead to gdnc launching.
3. Kill the app, so that the nameserver database remains (quiting the app in
a normal way should usually clean the database).
4. Kill gdnc.
5. Start the app again.

(Repeat steps 2-4 if the bug doesn't show yet.)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?22351

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



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

[bug #22351] GDNC not starting properly on some systems.

[Yavor Doganov]

Follow-up Comment #14, bug #22351 (project gnustep):

 No it's not safe to make any such assumption...

Ah, thanks.  So my approach is entirely unacceptable, as you said.

 Hopefully the changes to NSPortMessageNameServer.m to implement
 locking...

I'll test extensively tomorrow at work, they should apply cleanly and work
with 0.14 as well.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?22351

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



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

[bug #22351] GDNC not starting properly on some systems.

[Yavor Doganov]

Follow-up Comment #19, bug #22351 (project gnustep):

I tested yesterday's changes to NSMessagePortNameServer.m (as applied on the
stable branch) with Debian's Base 1.14.1 and everything works as expected.

Many thanks for fixing this annoying problem.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?22351

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



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

[bug #23792] PC cannot be built with LDFLAGS=-Wl,-z,defs

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?23792

 Summary: PC cannot be built with LDFLAGS=-Wl,-z,defs
 Project: GNUstep
Submitted by: yavor
Submitted on: Monday 07/07/2008 at 13:57
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

ProjectCenter from CVS fails to build with LDFLAGS=-Wl,-z,defs, since the
Framework uses symbols from libobjc and libgnustep-base but does not link with
them.

The attached trivial patch fixes this.



___

File Attachments:


---
Date: Monday 07/07/2008 at 13:57  Name: 05_link-libs.patch  Size: 674B   By:
yavor

http://savannah.gnu.org/bugs/download.php?file_id=16016

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?23792

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



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

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?24083

 Summary: Offset issues with the xmonad WM; blank windows
with the cairo backend
 Project: GNUstep
Submitted by: yavor
Submitted on: Sat Aug 16 22:41:26 2008
Category: Backend
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

A Debian user reported at http://bugs.debian.org/495373 that with xmonad WM
and the cairo backend he gets blank windows, very similar to the issue
reported for IceWM in bug #21571.

I can't reproduce it, although like him I get styleoffsets ... guessing
offsets on the console.

His configuration:
screen #0:
  dimensions:1280x1024 pixels (338x271 millimeters)
  resolution:96x96 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32
  root window id:0x7f
  depth of root window:24 planes

No special effects, compositing manager, etc.
Attached is his log with `--GNU-Debug=Offset'.



___

File Attachments:


---
Date: Sat Aug 16 22:41:26 2008  Name: offset-log  Size: 39kB   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=16301

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24083

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



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

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

[Yavor Doganov]

Follow-up Comment #2, bug #24083 (project gnustep):

I've never used xmonad, I just installed it to test this particular problem. 
Here is what the OP replied:

I have no idea what business has GNUstep with window borders. The
application draws into its window and the window location on the screen and
decorations are the business of the window manager.

Just set the offsets to 0 when the windows are not reparented, and if
somebody complains they can get the them calculated properly. With typical
configuration you would be at most one pixel off even if the value was
actually useful for something.

The default window border size for xmonad is 1, it seems.

The grey windows with the cairo backend are unrelated to xmonad -- the OP
says he gets the same behavior with Window Maker.  Any clues what might be the
cause?  His machine is amd64 (aka x86_64), FWIW.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24083

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



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

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

[Yavor Doganov]

Follow-up Comment #4, bug #24083 (project gnustep):

 I will need to know which version of cairo and 
 of GNUstep are being used. 

Based on his Debian suite, they are:

cairo 1.6.4
Base 1.16.1
Gui/Back 0.14.0

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24083

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



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

[bug #23876] gnustep-base does not build in a chrooted environment

[Yavor Doganov]

Follow-up Comment #8, bug #23876 (project gnustep):

AC_SYS_PROCFS is not a standard autoconf macro, just a macro polluting
autoconf's namespace (a common practice, unfortunately).

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?23876

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



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

[bug #23876] gnustep-base does not build in a chrooted environment

[Yavor Doganov]

Follow-up Comment #10, bug #23876 (project gnustep):

The macro definition is in config/procfs.m4.  I don't know where it came
from, but definitely not Autoconf.

The test being performed there is going to fail in chroots that do not mount
/proc.

FWIW, it doesn't fail on Debian autobuilders; from a Debian buildd log for
1.16.3:

checking procfs.h usability... no
checking procfs.h presence... no
checking for procfs.h... no
checking kernel support for /proc filesystem... yes
checking support for /proc psinfo struct... no
checking link to exe of process in /proc... /proc/self/exe
checking /proc/10669/cmdline terminated by nul... yes

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?23876

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



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

[bug #23876] gnustep-base does not build in a chrooted environment

[Yavor Doganov]

Follow-up Comment #11, bug #23876 (project gnustep):

I just tried in a pbuilder chroot (which mounts /proc) -- the `mount' command
outputs nothing.

The attached trivial patch should be equally reliable and should DTRT in such
chroots.  Funda Wang, does it work for you if you apply it and then run
`autoreconf -vi'?

(file #16321)
___

Additional Item Attachment:

File name: procfs.diffSize:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?23876

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



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

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS=-Wl, --as-needed -Wl, --no-undefined

[Yavor Doganov]

Follow-up Comment #3, bug #24109 (project gnustep):

It's not GNUstep Make's fault.  It is the developer's responsibility to
ensure that LIBRARIES_DEPEND_UPON contains all the libraries the built library
has to link with; gnustep-make does not add anything by default (and that's
how it should be, as it has no knowledge about the required libs).

The attached patch works for me.

(file #16326)
___

Additional Item Attachment:

File name: no-undefined.patch Size:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24109

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



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

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS=-Wl, --as-needed -Wl, --no-undefined

[Yavor Doganov]

Follow-up Comment #6, bug #24109 (project gnustep):

I can't speak for this particular case, but...

As per Debian Policy it is a bug if a program or a library has unresolved
symbols; this is to ensure that the shlibs system works properly and all
dependencies for the package are computed correctly (there are some exceptions
like python extensions, etc.)

Many packages pass `-Wl,--as-needed' during build to strip unnecessary
dependencies, and additionally `-Wl,-z,defs' for extra safety.  It appears
that this has become common practice for Fedora and Mandriva too.  Superfluous
dependencies just make library transitions harder (and user's experience too,
as they install extra packages they don't need), and missing dependencies
cause mystical runtime failures that are sometimes hard to debug.  (The latter
is almost impossible in this case, but still...)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24109

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



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

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

[Yavor Doganov]

Follow-up Comment #9, bug #24083 (project gnustep):

Many thanks...
The OP confirmed that the NSBezierPath.m patch resolves the problem with
cairo, so this bug remains for the (minor) xmonad issue.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24083

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?24526

 Summary: Crash on x86_64 when a program is started with
argument that is invalid property list
 Project: GNUstep
Submitted by: yavor
Submitted on: Sat Oct 11 00:07:44 2008
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This was reported at http://emacsbugs.donarmstrong.com/1079 as a bug in the
GNUstep port of Emacs.

Using the attached test program, on x86:

$ ./test --eval '(setq foo 1)'
Useless info about bundle: NSBundle: 0x813ec98 /usr/bin/Resources/test
'--eval' - a string.
'(setq foo 1)' failed with:
Parse failed  - Parse failed at line 1 (char 7) - unexpected character
(wanted ',' or ')').
Failure.
$ echo $?
1
$ NOHANDLE=yes ./test --eval '(setq foo 1)'
Useless info about bundle: NSBundle: 0x813ed18 /usr/bin/Resources/test
NOHANDLE defined; should exit with success.
$ echo $?
0

On x86_64, however, it crashes with a backtrace analogical to that when
bootstrapping Emacs
(http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1079#45).



___

File Attachments:


---
Date: Sat Oct 11 00:07:44 2008  Name: test.m  Size: 2kB   By: yavor
Test program
http://savannah.gnu.org/bugs/download.php?file_id=16649

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

Follow-up Comment #2, bug #24526 (project gnustep):

It was reproduced by the original bug reporter with gnustep-startup-0.20, but
I also asked him to try with Base SVN trunk -- same result.

I assume that you cannot reproduce on x86_64, right?

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

Follow-up Comment #4, bug #24526 (project gnustep):

Thanks.  If the `signal' implementation on that system is broken, I suspect
there would be other severe problems in Emacs that would occur before
byte-compiling the Emacs Lisp files.  We'll investigate.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

Follow-up Comment #5, bug #24526 (project gnustep):

A friend who is an official Debian Developer managed to reproduce this on
Debian GNU/Linux amd64 (sid), using the debian gnustep-base package (version
1.16.3), installed specifically for this test.

Attached are two files with backtraces -- one with the Emacs CVS (the
original problem), and another one with the test program.  They are almost
identical, and also identical to the ones at the Emacs bug report #1079.

If `signal' is broken on Debian unstable, that's a very grave problem.

(file #16693, file #16694)
___

Additional Item Attachment:

File name: backtrace-emacs.txtSize:5 KB
File name: backtrace-test-program.txt Size:8 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

Follow-up Comment #7, bug #24526 (project gnustep):

 but then a gdb backtrace of something different, not of the core  image
dumped. 

Correct, but in fact it is a crash while executing this preciese command from
the make recipe.  I can ask him to run gdb on the core, if it helps.  It has
nothing to do with Lisp stuff -- '(setq make-backup-files nil)' (or whatever)
is evaulated as property list which is an invalid array.  It seems to me that
-[NSUserDefaults __createArgumentDictionary] has a handler for this case, but
for some reason it doesn't work.

 so it's not clear whether they demonstrate any bug at all.

I guess you're right, but one thing is clear: both bootstrap-emacs and the
test program don't crash on x86, so there should be a bug somewhere.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

Follow-up Comment #8, bug #24526 (project gnustep):

One more thing.  Another person could not reproduce this on Debian Etch,
amd64, Base version 1.13.0.  The test program exited with code 1 and zero when
NOHANDLE is defined, as expected.

This (old) version of GNUstep Base does not have the specific code for the
handler we're talking about.  The default compiler in Etch is GCC 4.1, FWIW.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24785] Application not quitting properly on some platforms.

[Yavor Doganov]

Follow-up Comment #1, bug #24785 (project gnustep):

I can confirm this behavior with Preferences on GNU/kFreeBSD, GUI version
0.14.0.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24785

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



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

[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list

[Yavor Doganov]

Follow-up Comment #10, bug #24526 (project gnustep):

Sorry for replying so late.

I can't reproduce with Base 1.18.0 on x86_64-linux-gnu; I even managed to
bootstrap Emacs without other errors, which was quite surprising.  Please
close the bug, thanks.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24526

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



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

[bug #24083] Offset issues with the xmonad WM

[Yavor Doganov]

Follow-up Comment #17, bug #24083 (project gnustep):

Fred -- sorry for the delay.  The OP reports this is fixed in 0.16.0, so
please close.  Thanks!

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24083

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



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

[bug #26895] NSFontDescriptor.h not included from AppKit.h

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?26895

 Summary: NSFontDescriptor.h not included from AppKit.h
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri Jun 26 12:52:23 2009
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Perhaps I'm missing something, but I think that this is a bug.  Emacs.app
fails to build because of this, while it apparently succeeds on MacOS X:

http://emacsbugs.donarmstrong.com/3652

Trivial patch attached.



___

File Attachments:


---
Date: Fri Jun 26 12:52:23 2009  Name: NSFontDescriptor-include.patch  Size:
557B   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=18329

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?26895

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



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

[bug #27222] By default binaries should be built with '-g -O2'

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?27222

 Summary: By default binaries should be built with '-g -O2'
 Project: GNUstep
Submitted by: yavor
Submitted on: Tue 11 Aug 2009 12:02:16 AM EEST
Category: Makefiles
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This change

2006-09-20  Nicola Pero nicola.p...@meta-innovation.com

By default compile everything with debug=yes.  To get the
traditional behaviour, please use 'make debug=no'.
* common.make (debug): Turn on debug by default.

and the resulting comment and behavior:

# Enable debug by default.  This is according to the GNU Coding
# Standards.
ifneq ($(debug), no)
  debug = yes
endif

ifeq ($(debug), yes)
  # This is filtered out as it compromised debugging
  OPTFLAG := $(filter-out -O%, $(OPTFLAG))
...

is wrong.  The GNU Coding Standards require that packages should be built
with debugging symbols (-g) by default, but does not go so far in agressively
removing any optimization.  For example, '(standards)Configuration' says:

`VARIABLE=VALUE'
   ...
   For example, the user could issue `configure CFLAGS=-g
   CXXFLAGS=-g' to build with debugging information and
   without the default optimization.

For any package that uses the GNU Build System, if
CFLAGS/CXXFLAGS/OBJCFLAGS/etc are not specified by the user, they are set to
'-g -O2'.  This is a long time tradition, and GNUstep Make behaved this way
until the above change.

This is causing us grief in Debian as the Debian Policy requires all binaries
to be built with -O2 (unless there is a good reason for -O3); unoptimized
builds are considered a bug so we have lots of buggy GNUstep packages now
(from a Policy perspective, at least).




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?27222

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



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

[bug #27222] By default binaries should be built with '-g -O2'

[Yavor Doganov]

Follow-up Comment #2, bug #27222 (project gnustep):

I think there are still plenty of bugs on some targets with -O3 and higher,
so this seems risky.

I think this is most natural:

* debug=yes (default): -g -O2
* debug=no: -O2

If a developer/user wants unoptimized build for better debugging, `make
OPTFLAG=-O0' is the way to go, just like in a typical autoconfiscated package
one would do `./configure CFLAGS=-g'.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?27222

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



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

[bug #29208] NSCalendarDate's format does not support the %k conversion specifier

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?29208

 Summary: NSCalendarDate's format does not support the %k
conversion specifier
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 12 Mar 2010 03:41:18 PM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

While preparing the upload of SimpleAgenda/0.40 for Debian I discovered
something unpleasant -- the time in the app icon is displayed as
'%k,minutes,seconds' when run under Bulgarian locale.  This is because our
locale definition is '%k,%M,%S'.  (The %k specifier is a GNU extension
according to the glibc manual, which makes its use perfectly valid in a glibc
locale.)

Unfortunately NSCalendarDate (as documented) does not understand it.  I
checked the Cocoa documentation, and there's no %k there too (not
surprising).

Would you accept a patch implementing support for the %k specifier?  I hope
that Apple not implementing it won't be an obstacle...

AFAICS from the online documentation, `strftime' in FreeBSD, OpenSolaris and
even Mac OS X support it, so it's not something strictly GNU-specific.

The attached test program demonstrates the current ugliness:

$ LC_ALL=C ./obj/test
%H:%M:%S
15:37:17
$ LC_ALL=en_US.UTF-8 ./obj/test
%r
03:38:37 PM
$ ./obj/test
%k,%M,%S
%k,38,48



___

File Attachments:


---
Date: Fri 12 Mar 2010 03:41:18 PM EET  Name: test.m  Size: 401B   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=19920

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29208

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



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

[bug #29208] NSCalendarDate's format does not support the %k conversion specifier

[Yavor Doganov]

Follow-up Comment #2, bug #29208 (project gnustep):

Thanks.  Here is my attemt; I'd appreciate a thorough review.  The leading
space is important for sorting/alignment -- I see that %e omits it (contrary
to what the documentation says); probably to match Cocoa behavior?

Tested with the attached program (test2.m) as follows:


$ LC_ALL=C ./obj/test2
%H:%M:%S
04:03:30
(nil)
13:19:28
$ LC_ALL=en_US.UTF-8 ./obj/test2
%r
04:03:30 AM
(nil)
01:19:40 PM
$ ./obj/test2
%k,%M,%S
 4,03,30
 1,02,03
13,19,51
$ defaults write NSGlobalDomain GSMacOSXCompatible YES
$ LC_ALL=C ./obj/test2
%H:%M:%S
04:03:30
(nil)
13:20:20
$ LC_ALL=en_US.UTF-8 ./obj/test2
%r
04:03:30 AM
(nil)
01:20:31 PM
$ ./obj/test2
2010-03-13 13:20:45.223 test2[6349] Invalid NSCalendar date, specifier k not
recognized in format %k,%M,%S
%k,%M,%S
%k,03,30
(nil)
%k,20,45

P.S.  I'm not sure if my changes until now are already legally significant,
but either way (whether the patch is rejected or not), I'd be happy to assign
past and future changes to the FSF at any time.

(file #19929, file #19930)
___

Additional Item Attachment:

File name: k.patchSize:3 KB
File name: test2.mSize:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29208

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



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

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?29845

 Summary: FTBFS on GNU/Hurd with -Wl,--no-undefined
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon May 10 11:27:13 2010
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Building gnustep-base/1.19.3 on GNU/Hurd with LDFLAGS set to -Wl,-z,defs
-Wl,--as-needed fails during linking with:

/build/buildd-gnustep-base_1.19.3-2-hurd-i386-fh_Ygd/gnustep-base-1.19.3/Source/NSProcessInfo.m:921:
undefined reference to `gnustep_base_user_main'

Relevant portions from `configure' output:

checking procfs.h usability... no
checking procfs.h presence... no
checking for procfs.h... no
checking kernel support for /proc filesystem... no
checking support for /proc psinfo struct... no
checking link to exe of process in /proc... no
checking /proc/25986/cmdline terminated by nul... no
checking for kvm_getenvv in -lkvm... no
checking use of pass-through arguments... no
checking use of fake-main definition... yes

Toolchain packages used: libc0.3-dev_2.10.2-7 hurd-dev_20090404-2
gnumach-dev_2:1.3.99.dfsg.git20091128-1 gcc-4.4_4.4.4-1 binutils_2.20.1-9

Full build log:
https://buildd.debian.org/fetch.cgi?pkg=gnustep-basearch=hurd-i386ver=1.19.3-2stamp=1273445079file=logas=raw




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29845

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



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

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

[Yavor Doganov]

Follow-up Comment #3, bug #29845 (project gnustep):

No news, unfortunately.  I'd be glad to provide a patch if I only knew what
would be the correct fix...  It seems that all platforms which use the
GS_FAKE_MAIN hack are affected; on GNU/Linux you can reproduce the problem
with

  ./configure --enable-fake-main LDFLAGS=-Wl,--no-undefined

To your questions:

 I'm guessing it's a build of a debian source package?

That's right.

 1. Why is LDFLAGS set to -Wl,-z,defs -Wl,--as-needed ? 

The latter removes unnecessary dependencies.  When you link -lfoo and -lbar,
but you only need -lfoo, dpkg-shlibdeps will add an explicit package
dependency on the package providing libfoo.so.  -Wl,-z,defs is a safety check;
it enables symbol resolution at build time, to ensure that all objects are
linked against all libraries they use symbols from.

Note that this is not a Debian invention; most binary-based distros (Fedora,
Mandriva, etc.) use these flags for most packages, because this solves the
following vital issues:

1) package foo *must* depend on all packages it needs
2) in the ideal case package foo should not depend on any packages it doesn't
need,  because this causes inconvenience for users and more importantly,
complicates library transitions and the archive software (at least for
Debian)

 perhaps it's the cause of the problem?

Absolutely.  For the time being I workarounded the issue (to use only
--as-needed on GNU/Hurd).

 So the library is being built with the wrong objective-c library and/or
incorrectly 
 configured gnustep-make. 

Yes, this is fixed in 1.20.0-1, but this problem is not the culprit here.

 perhaps this bug report is obsolete

No, it's not.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29845

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


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

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

[Yavor Doganov]

Follow-up Comment #5, bug #29845 (project gnustep):

 Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to
'-Wl,--no-undefined' 

Almost; -Wl,-z,defs is another way of writing -Wl,--no-undefined.

 the fake main mechanism requires the gnustep_base_user_main() function to
be
 undefined as it is supplied by the program which is using gnsutep. 

Thanks... I never actually fully understood the fake-main thingy :-(
So it's not a bug, I agree.

 So this is more a package bug (building base with illegal linker flags)

(You mean invalid, illegal is something different and its use in this
context is discourged by the GNU Coding Standards.)

Yes, I agree the value of LDFLAGS is invalid for this platform, and it's a
Debian packaging bug for defining it.

 If there's a hurd specific way to obtain that info, we could change the
configure.ac to 
 detect its presence and add code to use it instead of fake-main. Do you
know of a 
 way to do it? 

IIRC one or two years ago there was a Hurd GSoC project for implementing a
GNU/Linux-compatible procfs translator.  AFAICS now, the code has been merged
into the Hurd repository and is available in the Debian hurd(-dev) package. 
So my wild guess is that /proc on GNU/Hurd is not mounted by default, which is
why the configure check fails.  I can use --enable-procfs when configuring
gnustep-base on this platform, but I have to recheck with the Hurd people
if/how it is guaranteed to have /proc on a live user GNU/Hurd system,
otherwise things may break at runtime.

Many thanks for enlightening me.  I suggest to close this bug; if it turns
out there are other related issues I'll follow up accordingly.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29845

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


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

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?30094

 Summary: (Regression) FTBFS on GNU/kFreeBSD: sync.m:87:
error: 'PTHREAD_MUTEX_RECURSIVE' undeclared
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed Jun  9 14:38:36 2010
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

1.20.0 fails to build on GNU/kFreeBSD with the following error:

gcc sync.m -c \
  -MMD -MP -Wall -Wdeclaration-after-statement -DGNUSTEP
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT
-fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fno-strict-aliasing
-fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime
-fgnu-runtime -fconstant-string-class=NSConstantString
-I../../Headers/Additions -I../. -I../ -I../../Headers -I.
-I/usr/include/GNUstep -I/usr/local/include/GNUstep
-I/usr/local/include/GNUstep -I/usr/include/libxml2 -I/usr/include
-I/usr/local/include/GNUstep -I/usr/include/GNUstep \
   -o obj/ObjectiveC2.obj/sync.m.o
sync.m: In function 'initLockObject':
sync.m:87: warning: implicit declaration of function
'pthread_mutexattr_settype'
sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this
function)
sync.m:87: error: (Each undeclared identifier is reported only once
sync.m:87: error: for each function it appears in.)
make[5]: *** [obj/ObjectiveC2.obj/sync.m.o] Error 1

Trivial patch attached.

GNU libc supports several kernels: Linux, GNU Mach+Hurd, kFreeBSD and
(unofficially) kOpenSolaris.  So the correct check in this case is for the
symbol __GLIBC__, which is guaranteed to be defined on all glibc-based
platforms.  
Perhaps it's worth to leave __linux__ for the rare cases when another libc is
used with Linux (uClibc, dietlibc, etc.), although I'm not sure if the GNUstep
stack works on those systems at all.

Thanks.



___

File Attachments:


---
Date: Wed Jun  9 14:38:36 2010  Name: kfreebsd.patch  Size: 610B   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=20708

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30094

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


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

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

[Yavor Doganov]

Follow-up Comment #8, bug #29845 (project gnustep):

Seems to be working fine.  Thank you very much.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29845

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


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

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

[Yavor Doganov]

Follow-up Comment #5, bug #30094 (project gnustep):

Strange, but if that works, OK.

There are 3 more places where this condition needs to be changed, could you
please do that?

GSPThread.h, NSLock.m, NSZone.m

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30094

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


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

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

[Yavor Doganov]

Follow-up Comment #9, bug #30094 (project gnustep):

Unfortunately I won't be able to confirm that the failure is fixed on
GNU/kFreeBSD until gnustep-base 1.20.x is uploaded to Debian (either with the
upstream fix, or the same as a Debian patch).  It's like a chicken and egg
problem for us...

So do whatever you think is right, and I'll followup later here with the
result.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30094

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


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

[bug #28014] [GWorkspace] Does not build *with* sqlite3

[Yavor Doganov]

Follow-up Comment #4, bug #28014 (project gnustep):

config.log should contain details about why this AC_CHECK_LIB test was
unsuccessful.  Could you please look and post the relevant output?

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?28014

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


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

[bug #30285] Compile issue on Solaris9/SPARC64

[Yavor Doganov]

Follow-up Comment #2, bug #30285 (project gnustep):

The Autoconf manual (node `Header Portability') says:

`inttypes.h' vs. `stdint.h'
 The C99 standard says that `inttypes.h' includes `stdint.h', so
 there's no need to include `stdint.h' separately in a standard
 environment.  Some implementations have `inttypes.h' but not
 `stdint.h' (e.g., Solaris 7), but we don't know of any
 implementation that has `stdint.h' but not `inttypes.h'.

So a simple solution seems to be to include inttypes.h only.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30285

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


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

[bug #30299] Renaissance needs to link against needed libraries

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?30299

 Summary: Renaissance needs to link against needed libraries
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 30 Jun 2010 10:13:52 AM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This is most probably never a problem at runtime, because any app that uses
Renaissance already links against libobjc, -base and -gui so the libraries are
loaded before Renaissance needs them.  However, it is causing us trouble in
Debian because the release team cannot reliably determine that the renaissance
package needs to be rebuilt during GNUstep transitions (because it doesn't
link against GNUstep libraries, the librenaissance0 package doesn't pick the
dependencies).

The attached patch has been in Debian for some time; I believe it is
completely safe.



___

File Attachments:


---
Date: Wed 30 Jun 2010 10:13:52 AM EEST  Name: link-libs.patch  Size: 471B  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=20857

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30299

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?30766

 Summary: Serious problems on hppa -- all programs abort with
malloc assertion failure
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 13 Aug 2010 12:41:01 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

It looks like 1.20.1 is severely broken on hppa-linux-gnu; see an example
backtrace below.  1.19.3 appears to work fine, so my conclusion is that this
is not due to anticipated toolchain problems on that platform.  Unfortunately,
this is a blocker for the ongoing GNUstep transition in Debian because hppa is
a release architecture.

Downstream bug report:
http://bugs.debian.org/592751

Starting program: /home/dannf/gnustep-gui-0.18.0/Tools/obj/make_services
--help
[Thread debugging using libthread_db enabled]
make_services: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd  old_size == 0) || ((unsigned long) (old_size) =
(unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2
* (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1))) 
((old_top)-size  0x1)  ((unsigned long)old_end  pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0x404a98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
67 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
   in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) thread apply all bt full

Thread 1 (Thread 0x40004b80 (LWP 20173)):
#0  0x404a98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
__r25 = 20173
__res = value optimized out
__r19 = value optimized out
__r24 = 6
__r26 = value optimized out
pd = 0x40004b80
pid = 20173
selftid = 20173
res = value optimized out
#1  0x404ae258 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = error reading variable,
sa_sigaction = error reading variable}, sa_flags = 4210038464, sa_mask =
{__val = {4210038416, 168, 1079839352, 1079839352, 1078825987, 1078825987,
951080, 946692, 4294967295, 946708, 1079839352, 1079830408, 288248, 372512,
18, 1086146538, 372280, 132, 1079839352, 1079839352, 1079847388, 1078941067,
951080, 946692, 4294967295, 946708, 1077441636, 295, 1079837304, 1079837304,
1079837304, 152}}}
sigs = {__val = {32, 0 repeats 31 times}}
#2  0x404ef084 in __malloc_assert (assertion=value optimized out,
file=value optimized out, line=value optimized out, function=value
optimized out) at malloc.c:352
No locals.
#3  0x404f2e74 in sYSMALLOc (av=0x405d29dc, bytes=344) at malloc.c:3094
snd_brk = value optimized out
front_misalign = value optimized out
remainder = value optimized out
tried_mmap = false
old_size = value optimized out
size = value optimized out
old_end = 0x5dc50 
correction = value optimized out
end_misalign = value optimized out
aligned_brk = value optimized out
p = value optimized out
pagemask = 4095
#4  _int_malloc (av=0x405d29dc, bytes=344) at malloc.c:4747
p = value optimized out
iters = value optimized out
nb = 352
idx = value optimized out
bin = value optimized out
victim = 0x5dc50
size = 0
victim_index = value optimized out
remainder = value optimized out
remainder_size = value optimized out
block = 4
bit = value optimized out
map = value optimized out
fwd = value optimized out
bck = value optimized out
errstr = value optimized out
__func__ = _int_malloc
#5  0x404f5588 in *__GI___libc_malloc (bytes=344) at malloc.c:3661
ar_ptr = 0x405d29dc
victim = 0x56
__func__ = __libc_malloc
#6  0x40379538 in objc_malloc (size=20173) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/misc.c:89
res = value optimized out
#7  0x4037adec in sarray_lazy_copy (oarr=0x45840) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sarray.c:507
num_indices = 86
#8  0x4037c7d8 in __objc_install_dispatch_table_for_class (class=0x40b5d3c4)
at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:442
super = 0x40b83030
#9  0x4037c868 in __objc_install_dispatch_table_for_class (class=0x40b5d19c)
at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:432
super = 0x40b5d3c4
#10 0x4037d1a0 in __objc_init_install_dtable (receiver=0x1fa68, op=value
optimized 

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #2, bug #30766 (project gnustep):

This happens with all programs (gdnc, pl2link, etc...)  It was discovered
while building gnustep-gui which invokes the just built make_services during
the build process.

 Could you please run this program under valgrind?

Valgrind is not available on this platform.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #4, bug #30766 (project gnustep):

 The later two could be ruled out by running a non GNUstep 
 Objective-C program compile don this machine.

Base 1.19.3 runs fine, so I guess they can be ruled out right away.

 Next you should check which of the different cases for argument
 inspection applies in your environment.

I don't have access to Debian's porter machines, but I can ask the bug
reporter to perform whatever tests are needed.

 Do you get any compiler warnings for GNUstep base?

Yes, many, particularly cast increases required alignment of target type. 
See attached file warnings.txt; full build log available at
https://buildd.debian.org/fetch.cgi?pkg=gnustep-basearch=hppaver=1.20.1-2stamp=1281448914file=logas=raw.

(file #21236)
___

Additional Item Attachment:

File name: warnings.txt   Size:18 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #5, bug #30766 (project gnustep):

Here is some information about this architecture, in case it can be of help.

Type size:
short 2
int   4 
long  4
long long 8
float 4
double8
long double   8
data pointer  4

endianness: big
unaligned access not OK
char signedness: s
stack grows up (the only platform where this is so)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #8, bug #30766 (project gnustep):

 Base 1.19.3 runs fine, so I guess they can be ruled out right
 away.

 Unfortunately not as it's perfectly possible for some code to 
 trigger bugs in the compiler or runtime that other code does
 not trigger.

Right, I was thinking along the same line as well right after I sent the
message.  Today I got an account on the GCC compile farm
(http://gcc.gnu.org/wiki/CompileFarm) and could not reproduce the problem on
gcc61.fsffrance.org with Base 1.20.1, compiled with manually built GCC 4.4.4. 
I'm now building the same version of GCC + Debian-specific patches; if it
exposes the problem, I'll pass the hot potato to the Debian GCC maintainers. 
But we'll still need some workaround to get functional GNUstep on this
architecture.

 My only new idea on how to proceed is to try a bisection
 of the code changes since 1.19.3.

Yes, I was going to do exactly this if I was fortunate enough to reproduce.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #9, bug #30766 (project gnustep):

FYI: I asked the original bug reporter to try 1.20.0; it still fails in the
same way.

I'll wait for my tests with a debianized gcc before doing anything else.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #11, bug #30766 (project gnustep):

Here is another backtrace from a different program (test3.m) that doesn't use
NSProcessInfo:

Program received signal SIGABRT, Aborted.
0x40fc98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
67  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
#0  0x40fc98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x40fce258 in *__GI_abort () at abort.c:92
#2  0x4100f084 in __malloc_assert (assertion=value optimized out,
file=value optimized out, line=value optimized out, function=value
optimized out) at malloc.c:352
#3  0x41012e74 in sYSMALLOc (av=0x410f29dc, bytes=24) at malloc.c:3094
#4  _int_malloc (av=0x410f29dc, bytes=24) at malloc.c:4747
#5  0x41015588 in *__GI___libc_malloc (bytes=24) at malloc.c:3661
#6  0x40b88538 in objc_malloc (size=11523) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/misc.c:89
#7  0x4089cd00 in default_malloc (zone=value optimized out, size=11523) at
NSZone.m:124
#8  0x4089c508 in NSZoneMalloc (zone=value optimized out, size=11523) at
NSZone.m:2013
#9  0x4089ced0 in NSZoneCalloc (zone=0x2d03, elems=value optimized out,
bytes=6) at NSZone.m:1964
#10 0x407b3aec in GSIMapResize (self=0x3cb88, _cmd=value optimized out,
observer=value optimized out, selector=value optimized out, name=0x50118,
object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:741
#11 GSIMapRightSizeMap (self=0x3cb88, _cmd=value optimized out,
observer=value optimized out, selector=value optimized out, name=0x50118,
object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:770
#12 GSIMapInitWithZoneAndCapacity (self=0x3cb88, _cmd=value optimized out,
observer=value optimized out, selector=value optimized out, name=0x50118,
object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:1218
#13 mapNew (self=0x3cb88, _cmd=value optimized out, observer=value
optimized out, selector=value optimized out, name=0x50118, object=0x0) at
NSNotificationCenter.m:326
#14 -[NSNotificationCenter addObserver:selector:name:object:] (self=0x3cb88,
_cmd=value optimized out, observer=value optimized out, selector=value
optimized out, name=0x50118, object=0x0) at NSNotificationCenter.m:786
#15 0x4085b944 in +[NSTimeZone initialize] (self=value optimized out,
_cmd=value optimized out) at NSTimeZone.m:1297
#16 0x40b8bd44 in __objc_send_initialize (class=0x409f686c) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#17 0x40b8c200 in __objc_init_install_dtable (receiver=0x409f686c, op=value
optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#18 objc_msg_lookup (receiver=0x409f686c, op=value optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#19 0x406e73d4 in +[NSCalendarDate initialize] (self=value optimized out,
_cmd=value optimized out) at NSCalendarDate.m:356
#20 0x40b8bd44 in __objc_send_initialize (class=0x409b3e98) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#21 0x40b8c200 in __objc_init_install_dtable (receiver=0x409b3e98, op=value
optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#22 objc_msg_lookup (receiver=0x409b3e98, op=value optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#23 0x40736fe4 in +[NSDate initialize] (self=0x409be69c, _cmd=value
optimized out) at NSDate.m:137
#24 0x40b8bd44 in __objc_send_initialize (class=0x409be69c) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#25 0x40b8c200 in __objc_init_install_dtable (receiver=0x409be69c, op=value
optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#26 objc_msg_lookup (receiver=0x409be69c, op=value optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#27 0x40887ef0 in +[NSUserDefaults initialize] (self=value optimized out,
_cmd=value optimized out) at NSUserDefaults.m:298
#28 0x40b8bd44 in __objc_send_initialize (class=0x40a032fc) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#29 0x40b8c200 in __objc_init_install_dtable (receiver=0x40a032fc, op=value
optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#30 objc_msg_lookup (receiver=0x40a032fc, op=value optimized out) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#31 0x40889270 in GSPrivateDefaultsFlag (type=GSLogSyslog) at
NSUserDefaults.m:2141
#32 0x407ad414 in NSLogv (format=0x127cc, args=0xfaf0169c) at NSLog.m:305
#33 0x407ada5c in NSLog (format=value optimized out) at NSLog.m:252
#34 0x0001095c in -[NCTest notified:] (self=0x511c8, _cmd=0x128e0,
notif=0x51450) at test.m:13
#35 0x407b4424 in 

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #13, bug #30766 (project gnustep):

I asked the bug reporter to commence the bisection procedure, starting from
the tip (just in case), then narrowing between the last good r28586 (1.19.3)
and bad r30325 (1.20.0).

I'll followup here with the results as soon as I have them.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #15, bug #30766 (project gnustep):

Further narrowed down to -r28600:r28625 (continuing).

I asked on debian-hppa about some information for the switch from
Linuxthreads to NPTL on hppa -- I remember it was very hard, and there were
some odd details.  It may turn out to be a glibc bug (which explains why I
can't reproduce with glibc 2.7, which is using the old Linuxthreads).  Or
maybe not, so please try to investigate.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #16, bug #30766 (project gnustep):

Final results:

- r28611 is ok
- r28612 didn't compile [1]
- r28613 exposes the bug

[1]
NSLock.m: In function ‘-[NSCondition lockBeforeDate:]’:
NSLock.m:247: warning: passing argument 1 of ‘pthread_mutex_trylock’
from
incompatible pointer type
/usr/include/pthread.h:732: note: expected ‘union pthread_mutex_t *’ but
argument is of type ‘struct pthread_mutex_t *’
NSLock.m: At top level:
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
make[4]: *** [obj/libgnustep-base.obj/NSLock.m.o] Error 1
make[3]: *** [internal-library-all_] Error 2
make[2]: *** [libgnustep-base.all.library.variables] Error 2
make[1]: *** [internal-all] Error 2
make: *** [internal-all] Error 2

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #17, bug #30766 (project gnustep):

Looking at the diff, the only thing that comes to (my) mind is some oddity
with hiding the pthread stuff (hppa has the largest size of pthread_mutex_t --
48 -- but this shouldn't be a problem AFAICS), or the NSRunLoop change. 
Should I ask to revert either of them and repeat the test?

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #18, bug #30766 (project gnustep):

FWIW, link to the discussion that lead to this particular change:
http://thread.gmane.org/gmane.comp.lib.gnustep.general/33167

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #19, bug #30766 (project gnustep):

I asked Carlos O'Donnel, the author of the glibc NPTL code for hppa if
there's something wrong in the approach of hiding pthread internals with
opaque types of the same size.  He said:

Yes, you don't take into account the alignment requirement of the
structure.

The pthread_mutex_t and pthread_cond_t on hppa are __attribute__
((aligned(16))), which means if you embedded them into another
structure they need to be padded out to that alignment. The dummy
structure you use here doesn't match the alignment and may break ABI.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #21, bug #30766 (project gnustep):

Yes, I'm glad to confirm this fixes the problem.  It was not tested on the
official autobilders yet, but I doubt there will be any problems (and if there
are, they would be entirely my fault when incorporating the patch).

Thanks very much!

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #23, bug #30766 (project gnustep):

How does it fail exactly?  Can you post the relevant portions from
config.log?

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #25, bug #30766 (project gnustep):

Looks like pthread.h is not included in the test program.  See if the
attached patch helps.

(file #21281)
___

Additional Item Attachment:

File name: AC_CHECK_ALIGNOF.patch Size:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?30766

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


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

[bug #42410] gdomap does not support IPv6

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42410

 Summary: gdomap does not support IPv6
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 23 May 2014 07:43:54 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This was reported at Debian:
http://bugs.debian.org/741442

From a short look at gdomap's source code, it doesn't seem to support IPv6 at
all.

I'm not sure it does support changing IP addresses as are common on, for
example, laptops either.




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42410

___
  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 #42411] gdomap chroots to /tmp

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42411

 Summary: gdomap chroots to /tmp
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 23 May 2014 07:54:06 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Another report from Debian, original URL:
http://bugs.debian.org/741441

gdomap chroots to /tmp as another level of paranoia. However if you are
paranoid, you really want to chroot to an empty, non-writable directory, not
to a world-writable one containing random files.




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42411

___
  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 #42423] base.make errouneously pollutes CONFIG_SYSTEM_* variables

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42423

 Summary: base.make errouneously pollutes CONFIG_SYSTEM_*
variables
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 26 May 2014 01:38:46 AM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This change

http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/base.make.in?r1=37409r2=37408pathrev=37409

is clearly wrong.  You don't really want everything that uses Base to be
linked with ICU, Avahi, GnuTLS, libxslt, libffi, etc.I don't really
understand the rationale for removing the make conditional -- if GUI needs ICU
(as it does), it needs to check for ICU itself (as it does).  There's no need
for Base to impose the libraries it uses to other packages.  Furthermore,
literally everything fails to build if built in a chroot or with special
linker flags, for example Cynthiune:

gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed
-Wl,-rpath,/usr/lib/cynthiune.app -pthread -shared-libgcc -fexceptions -o
./MP3.format/./MP3 ./obj/MP3.obj/xing.c.o ./obj/MP3.obj/MP3.m.o 
-L/usr/local/lib -L/usr/lib   -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed
-L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/lib/x86_64-linux-gnu 
-lmad  -lid3tag -lz   
-L../../Frameworks/Cynthiune/Cynthiune.framework/Versions/Current -lCynthiune 
 -lgnustep-gui-lgnustep-base-lobjc   -lavahi-common -lavahi-client 
-lgnutls  -lgcrypt -lxslt -lxml2 -lffi  -lrt -ldl  -lpthread -lz -licui18n
-licuuc -licudata  -lm
/usr/bin/ld: cannot find -lavahi-common
/usr/bin/ld: cannot find -lavahi-client
/usr/bin/ld: cannot find -lxslt
/usr/bin/ld: cannot find -lffi
collect2: error: ld returned 1 exit status
/usr/share/GNUstep/Makefiles/Instance/bundle.make:205: recipe for target
'MP3.format/./MP3' failed




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42423

___
  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 #42433] [cairo] FTBFS with -Wl,--no-undefined

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42433

 Summary: [cairo] FTBFS with -Wl,--no-undefined
 Project: GNUstep
Submitted by: yavor
Submitted on: Tue 27 May 2014 01:29:47 AM EEST
Category: Backend
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The cairo backend fails to build from source with strict linker flags because
it is not being linked with fontconfig.  In configure.ac it is wrongly assumed
that -lfontconfig will be inherited from Xft, but that is no longer the case:

$ grep ^Libs /usr/lib/*/pkgconfig/xft.pc 
Libs: -L${libdir} -lXft

Trivial patch attached.



___

File Attachments:


---
Date: Tue 27 May 2014 01:29:47 AM EEST  Name: fontconfig-libs.patch  Size:
786B   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31444

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42433

___
  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 #42606] libopal: unfortunate library name

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42606

 Summary: libopal: unfortunate library name
 Project: GNUstep
Submitted by: yavor
Submitted on: Tue 24 Jun 2014 05:28:14 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The choice for the library name is unfortunate because such library already
exists: http://www.opalvoip.org.  I believe it is widespread enough since
Ekiga, the GNOME VoIP application, uses it.  Both libraries provide
$(libdir)/libopal.so, which makes it impossible to coexist on one system in
packaged form.  There can't be two different libraries with identical binary
package names (libopal-dev), either.

Worse, this is not only a packaging issue.  A program using GNUstep opal will
happily (attempt to) link against the VoIP opal if they're installed on the
same system with different prefix, because the VoIP libopal library version is
greater.

Please consider renaming at least the LIBRARY_NAME in order to provide a
unique SONAME.  Trivial patch attached.



___

File Attachments:


---
Date: Tue 24 Jun 2014 05:28:14 PM EEST  Name: libopal-rename.patch  Size: 1kB 
 By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31610

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42606

___
  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 #42640] GNUstep Make does not honor CFLAGS

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42640

 Summary: GNUstep Make does not honor CFLAGS
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 02:05:00 PM EEST
Category: Makefiles
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Currently, Make does not honor user-specified CFLAGS.  As the manual says,
this variable is reserved for the user, much like OBJCFLAGS.  The bug can be
reproduced easily with ctool.make or any of tool/application/framework.make
having xxx_C_FILES defined.

Patch attached.



___

File Attachments:


---
Date: Sun 29 Jun 2014 02:05:00 PM EEST  Name: honor-CFLAGS.patch  Size: 521B  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31631

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42640

___
  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 #42641] Use makeinfo --html to generate HTML manuals from .texi documents

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42641

 Summary: Use makeinfo --html to generate HTML manuals from
.texi documents
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 07:08:06 PM EEST
Category: Makefiles
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I propose to switch to makeinfo for producing HTML variants of the Texinfo
manuals.  Rationale:

* texi2html is no longer developed
* the main texi2html author has been working on texinfo since quite some time
and the general advice is to migrate to texinfo (see [1])
* modern texinfo implements (almost) all the texi2html features
* texi2html is likely to be removed from some distros in the not-so-distant
future (see [2])
* makeinfo is more likely to be installed on a system
* one dependency less is generally a good thing

Cons: As makeinfo is more strict than texi2html, some documents which
previously built with texi2html will fail with makeinfo --html, just like they
are currently failing when building the .info file(s).  Since gnustep-make by
design ignores such errors, they are not fatal.  But I don't think that
documents with invalid Texinfo syntax are a valid reason to stick with
texi2html; they should be fixed instead.

[1] http://www.nongnu.org/texi2html/
[2] http://lists.debian.org/debian-devel/2013/05/msg01516.html

Please find attached the proposed patch implementing the switch.  texi2html as
a possibility is retained and can be used if required by the user.  I have
tested all four combinations (makeinfo/texi2html/split/monolithic) for the
common targets all/clean/install/uninstall.



___

File Attachments:


---
Date: Sun 29 Jun 2014 07:08:06 PM EEST  Name: makeinfo-html.patch  Size: 6kB  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31632

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42641

___
  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 #42642] Use -include directive for deb.make

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42642

 Summary: Use -include directive for deb.make
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 07:27:24 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Perhaps I'm missing something, but I fail to see why deb.make should be a hard
requirement.  The attached obvious patch makes Base buildable with older
versions of gnustep-make.



___

File Attachments:


---
Date: Sun 29 Jun 2014 07:27:24 PM EEST  Name: deb-make.patch  Size: 401B   By:
yavor

http://savannah.gnu.org/bugs/download.php?file_id=31633

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42642

___
  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 #42645] Use libgcrypt only if needed

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42645

 Summary: Use libgcrypt only if needed
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 09:36:19 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Currently, +[GSTLSObject initialize] calls uncoditionally gcry_control, which
is superfluous with recent (~4 years old) GnuTLS releases.
As of version 2.11 GnuTLS does not depend on gcrypt initialization, as its
NEWS file indicates:

** libgnutls: Added gnutls_global_set_mutex() to allow setting
alternative locking procedures. By default the system available
locking is used. In *NIX pthreads are used and in windows the
critical section API. This follows a different approach than the
previous versions that depended on libgcrypt initialization. The
locks are now set by default in systems that support it. Programs
that used gcry_control() to set thread locks should insert it into a block of
#if GNUTLS_VERSION_NUMBER = 0x020b00
gcry_control(...)
#endif


Version 2.11.1 switched to nettle as the default crypto backend, and support
for libgcrypt was removed entirely in 2.99.2.

Proposed patch attached.

(P.S.  The AC_MSG_WARN call if gcrypt is not found is redundant since there is
AC_MSG_ERROR a few lines below.  As a side (minor) issue, it is considered
poor practice to nest AC_MSG_CHECKING/AC_MSG_RESULT because it leads to ugly
and/or confusing output like:

checking gnutls support... checking for gcry_control in -lgcrypt... yes
yes
checking for gnutls_transport_set_errno... yes

It is not immediately clear to the user what the lone yes is for.  It is
even more confusing if there are mixed yes and no results.)



___

File Attachments:


---
Date: Sun 29 Jun 2014 09:36:19 PM EEST  Name: use-gcrypt-if-needed.patch 
Size: 2kB   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31636

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42645

___
  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 #24109] gnustep-gui 0.14.0 does not build with LDFLAGS=-Wl, --as-needed -Wl, --no-undefined

[Yavor Doganov]

Follow-up Comment #8, bug #24109 (project gnustep):

Nicola wrote:
 libgnustep-gui is not linked against libobjc. 
 That is done on purpose (eg see #9920). 

It is not clear from that bug *why* it is done on purpose...

 So ... what advantages would this change bring ? 

It's the other way around -- what advantages does it bring if not linking?

Richard wrote:
 If we changed the compatibility layer in GSObjCRuntime.h in 
 the base library so that we wrapped all of the runtime 
 functions, libraries would be able to link with just base
 and not libobjc. 

GUI uses libobjc directly at least in GSTheme, I think.  But apart from that,
is your proposal possible at all?  Aren't Objective-C libraries/applications
expected to be able to call runtime functions without hassle if they wish so? 
Isn't linking also needed for proper initialization (admittedly, this happens
anyway as the app is linked with the runtime)?

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?24109

___
  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 #42648] Manual page for gnustep-tests

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42648

 Summary: Manual page for gnustep-tests
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 11:10:58 PM EEST
Category: Makefiles
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Plus two typo fixes.  Patch attached.



___

File Attachments:


---
Date: Sun 29 Jun 2014 11:10:58 PM EEST  Name: manpage-fixes.patch  Size: 4kB  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31637

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42648

___
  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 #42649] Bootstrapping issue with the documentation

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42649

 Summary: Bootstrapping issue with the documentation
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 30 Jun 2014 01:17:49 AM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Base attempts to be bootstrap-friendly by defining AUTOGSDOC to the local
(just built) version.  However, this doesn't work because autogsdoc needs the
Base library to run and it is not installed yet.  In addition, there are
gazillion of warnings from autogsdoc for invalid documents -- not surprising,
since the DTDs are not installed yet, too.

The attached patch addresses these issues.



___

File Attachments:


---
Date: Mon 30 Jun 2014 01:17:49 AM EEST  Name: use-local-DTDs.patch  Size: 2kB 
 By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31638

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42649

___
  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 #42650] Tools are linked with unnecessary libraries

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42650

 Summary: Tools are linked with unnecessary libraries
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 30 Jun 2014 01:53:23 AM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

All of the Base tools are being linked with a lot of libraries they don't
need:

gcc  -rdynamic -shared-libgcc  -pthread -fexceptions -fgnu-runtime -o
obj/make_strings \
./obj/make_strings.obj/make_strings.m.o
./obj/make_strings.obj/SourceEntry.m.o ./obj/make_strings.obj/StringsEntry.m.o
./obj/make_strings.obj/StringsFile.m.o \
  -L../../Source/./obj
-L/home/yavor/GNUstep/Library/Libraries
-L/usr/local/lib -L/usr/lib   -L/usr/local/lib -L/usr/local/lib -L/usr/lib
-L/usr/lib/x86_64-linux-gnu  -L/usr/local/lib -L/usr/local/lib -L/usr/lib
-L/usr/lib/x86_64-linux-gnu-lgnustep-base-lobjc   -lavahi-common
-lavahi-client  -lgnutls   -lgcrypt -lxslt -L/usr/lib -lxml2 -lffi   -lrt -ldl
 -lpthread -lz -licui18n -licuuc -licudata  -lavahi-common -lavahi-client 
-lgnutls   -lgcrypt -lxslt -L/usr/lib -lxml2 -lffi   -lrt -ldl  -lpthread -lz
-licui18n -licuuc -licudata  -lm


This happens because CONFIG_SYSTEM_LIBS is defined in config.mak (as it
should; the Base library must link with all these libraries) and it
automatically applies for the tools -- their makefiles include config.mak. 
The attached patch fixes this.  Please note that this bug is independent to
Bug#42423, which is far more serious because the same thing happens to every
package that uses GNUstep Base.



___

File Attachments:


---
Date: Mon 30 Jun 2014 01:53:23 AM EEST  Name: avoid-tools-extra-linkage.patch 
Size: 874B   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31639

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42650

___
  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 #29730] Build attempt when typing 'make distclean' twice

[Yavor Doganov]

Follow-up Comment #3, bug #29730 (project gnustep):

Here is a proposed patch to fix this issue.  While here, I also fixed
clean/distclean so that all generated files are deleted.  The comments are
probably more verbose than needed, feel free to trim them.

P.S. Tests/base/NSInvocationOperation/GNUmakefile should be removed from the
repository.

(file #31642)
___

Additional Item Attachment:

File name: fix-distclean.patchSize:4 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29730

___
  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 #42693] Fix build on mips64(el) with GCC

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42693

 Summary: Fix build on mips64(el) with GCC
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 07 Jul 2014 05:48:44 AM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

GCC defines only __mips64, not __mips64__.  AFAICS clang defines both so this
change should be safe (patch attached).



___

File Attachments:


---
Date: Mon 07 Jul 2014 05:48:44 AM EEST  Name: mips64.patch  Size: 950B   By:
yavor

http://savannah.gnu.org/bugs/download.php?file_id=31682

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42693

___
  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 #42698] Recommended future steps for gnustep-dl2 debian package maintenance

[Yavor Doganov]

Follow-up Comment #4, bug #42698 (project gnustep):

I am not sure it was in the same discussion.  Anyway.  The dependency on
Renaissance is not a problem at all.

 I even made the case that libEOModeler could be 
 shipped with DBModeler here 

It is exactly what we are doing.

Perhaps we should use the opportunity of the soname bump (all GDL2 libraries
need it AFAICT) to split the package in a better way.  You are correct that
the right split is into non-gui and gui stuff.  Maybe we could lump the
adaptors together (MySQL+Postgres in one package) at the expense of the
gui-non-gui split.  That's what I did for SQLClient (all 4 bundles in the
library package), as it doesn't make sense to have separate packages for a few
KB.
The additional dependency on libmsysqlclient or libpq is negligible compared
to the things GUI/Back pull in.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42698

___
  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 #42698] Recommended future steps for gnustep-dl2 debian package maintenance

[Yavor Doganov]

Follow-up Comment #2, bug #42698 (project gnustep):

We can try to ship both apps with a bit of effort.  EOModeler is distributed
as a private library in Debian, because David Ayers once told us it was going
to undergo major changes.  Is the current split what he meant back then?  What
are the advantages of the new app over DBModeler?  Not working with the
palette is a big minus AFAICT.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42698

___
  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 #42698] Recommended future steps for gnustep-dl2 debian package maintenance

[Yavor Doganov]

Follow-up Comment #5, bug #42698 (project gnustep):

 (MySQL+Postgres in one package)

Of course I meant SQLite, not MySQL.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42698

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42717

 Summary: Crash in -[NSBox(Private)
calcSizesAllowingNegative:]
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 09 Jul 2014 04:48:17 PM EEST
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Cenon crashes on startup on a 32-bit system (cannot reproduce on
amd64/x86_64):


Program received signal SIGSEGV, Segmentation fault.
objc_msg_lookup (receiver=0x85ebc50, op=0xff98)
at /build/gcc-4.9-C54cEj/gcc-4.9-4.9.0/src/libobjc/sendmsg.c:448
448 /build/gcc-4.9-C54cEj/gcc-4.9-4.9.0/src/libobjc/sendmsg.c: Няма
такъв файл или директория.
(gdb) bt full
#0  objc_msg_lookup (receiver=0x85ebc50, op=0xff98)
at /build/gcc-4.9-C54cEj/gcc-4.9-4.9.0/src/libobjc/sendmsg.c:448
result = optimized out
#1  0xb7b741b9 in -[NSBox(Private) calcSizesAllowingNegative:] (
self=0xbfffe940, _cmd=0x921f4a8, aFlag=88 'X') at NSBox.m:757
titleSize = optimized out
c = optimized out
topMargin = optimized out
borderSize = optimized out
topOffset = optimized out
theme = optimized out
r = {origin = {x = 0, y = 0}, size = {width = 0, height = 0}}
#2  0x in ?? ()
No symbol table info available.
(gdb) frame 1
#1  0xb7b741b9 in -[NSBox(Private) calcSizesAllowingNegative:] (
self=0xbfffe940, _cmd=0x921f2b0, aFlag=88 'X') at NSBox.m:757
757 NSBox.m: Няма такъв файл или директория.
(gdb) po [GSTheme theme]
GSTheme: 0x85ebc50
(gdb) p _border_type
$8 = 143517512


GNUstep GUI 0.24.0, no themes installed.




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #2, bug #42717 (project gnustep):

Yep, I noticed that dubious aFlag too.  It looks like it is exactly the same
problem that was reported in 2013.

If I put a break on -[NSBox setBorderType:], aType is garbage (10-digit
number) instead of the expected value of 3.  Going further back to
-[GSXibKeyedUnarchiver decodeObjectForXib:forClassName:withID:], o is
optimized on i386, while it is not on amd64.  So I tried with gnustep-gui
rebuilt with no optimization (-O0) and the problem doesn't happen -- Cenon
starts and works.  Hope that this gives you some clue.  

It seems that -allocObjectForClassName: doesn't return a valid object and then
it gets messy in -initWithCoder:.  But I may be wrong here.
I'd appreciate any directions how to proceed further.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #3, bug #42717 (project gnustep):

When built with -O1, -calcSizesAllowingNegative: doesn't crash when called
from -setBorderType: (aType there is 3 as expected) but from
-setTitlePosition:


Breakpoint 1, -[NSBox setTitlePosition:] (self=0x921f6b0, 
_cmd=0xb7edb618 _OBJC_SELECTOR_TABLE+600, aPosition=NSAtTop)
at NSBox.m:192
192 {
(gdb) n
193   if (_title_position != aPosition)
(gdb) 
195   _title_position = aPosition;
(gdb) 
196   [_content_view setFrame: [self calcSizesAllowingNegative: NO]];
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x0921f6c9 in ?? ()
(gdb) bt
#0  0x0921f6c9 in ?? ()
#1  0x4250 in ?? ()
#2  0x00180071 in ?? ()
#3  0xb7edab8b in _OBJC_METH_VAR_TYPE_5 ()
   from /usr/lib/libgnustep-gui.so.0.24
#4  0x00120056 in ?? ()
#5  0xb7edab95 in _OBJC_METH_VAR_TYPE_4 ()
   from /usr/lib/libgnustep-gui.so.0.24
#6  0x000c0080 in ?? ()
#7  0xb7edab95 in _OBJC_METH_VAR_TYPE_4 ()
   from /usr/lib/libgnustep-gui.so.0.24
#8  0x00190069 in ?? ()
#9  0xb7edab95 in _OBJC_METH_VAR_TYPE_4 ()
   from /usr/lib/libgnustep-gui.so.0.24
#10 0x000f0036 in ?? ()
#11 0xb7edab6c in _OBJC_METH_VAR_TYPE_15 ()
   from /usr/lib/libgnustep-gui.so.0.24
#12 0x000d0080 in ?? ()
#13 0xb7edab6c in _OBJC_METH_VAR_TYPE_15 ()
   from /usr/lib/libgnustep-gui.so.0.24
#14 0x000e0080 in ?? ()
#15 0xb7edab20 in _OBJC_METH_VAR_TYPE_17 ()
   from /usr/lib/libgnustep-gui.so.0.24
#16 0x00090001 in ?? ()
#17 0xb7edab6c in _OBJC_METH_VAR_TYPE_15 ()
   from /usr/lib/libgnustep-gui.so.0.24
#18 0x000a0001 in ?? ()
#19 0xb7eda9a7 in _OBJC_METH_VAR_TYPE_85 ()
   from /usr/lib/libgnustep-gui.so.0.24
#20 0x00130003 in ?? ()
#21 0xb7eda991 in _OBJC_METH_VAR_TYPE_87 ()
   from /usr/lib/libgnustep-gui.so.0.24
#22 0x000f0080 in ?? ()
#23 0xb7edaafb in _OBJC_METH_VAR_TYPE_21 ()
   from /usr/lib/libgnustep-gui.so.0.24
#24 0x00100080 in ?? ()
#25 0xb7eda940 in ?? () from /usr/lib/libgnustep-gui.so.0.24
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Corrupt stack again.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42729] [DBusKit] Unnecessary libtool usage

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42729

 Summary: [DBusKit] Unnecessary libtool usage
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 04:26:11 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

DBusKit attempts to use libtool, but that is impossible as it stands.  You
either have to use Automake which has built-in support for libtool, or
write/implement libtool-aware rules (which is not straightforward and would
probably conflict with gnustep-make's rules).  Furthermore, using libtool is
not needed, because GNUstep Make supports shared libraries, albeit in a much
less sophisticated manner.

DBUS_LIBS and MORE_LIBS should be added to LIBRARIES_DEPEND_UPON and not
LDFLAGS so that the libs are added after the objects that are being linked in
and not as linker options (that will fail on some systems).

Perhaps the test for libclang should be conditionalized and not performed if
CC/OBJC is not clang (I have not addressed this in the patch as I'm not
certain about the implications).

The 0.1.1 tarball contains a libtool script which should never be distributed
(it is configuration-dependent).  Also there are a bunch of object files which
shouldn't be there, too.



___

File Attachments:


---
Date: Fri 11 Jul 2014 04:26:11 PM EEST  Name: no-libtool.patch  Size: 673B  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31699

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42729

___
  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 #42730] [DBusKit] Misc texinfo formatting fixes

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42730

 Summary: [DBusKit] Misc texinfo formatting fixes
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 06:06:44 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

There are several warnings from makeinfo, this patch fixes them along with
some other issues.

* install-info will fail without @dircategory
* use @direntry instead of direct info format
* align entry to recommended column 32
* use @copying for the copyright/license blurb so that it is added as comment
to all output formats
* avoid multiple @title
* @menu should not be wrapped in @ifinfo conditionals, otherwise makefinfo
cannot figure out the structure of the document for other formats
* menu items are inserted verbatim and should be wrapped, otherwise the result
is ugly/hard to read



___

File Attachments:


---
Date: Fri 11 Jul 2014 06:06:44 PM EEST  Name: manual.patch  Size: 2kB   By:
yavor

http://savannah.gnu.org/bugs/download.php?file_id=31700

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42730

___
  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 #42732] [Performance] Uses Base but doesn't link with it

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42732

 Summary: [Performance] Uses Base but doesn't link with it
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 07:55:19 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Trivial patch attached.



___

File Attachments:


---
Date: Fri 11 Jul 2014 07:55:19 PM EEST  Name: link-libs.patch  Size: 295B  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31702

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42732

___
  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 #42733] [SQLClient] Uses Base but doesn't link with it

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42733

 Summary: [SQLClient] Uses Base but doesn't link with it
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 08:21:59 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Patch attached.



___

File Attachments:


---
Date: Fri 11 Jul 2014 08:21:59 PM EEST  Name: link-libs.patch  Size: 556B  
By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31703

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42733

___
  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 #42734] [SQLClient] Unused config.{sub,guess}

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42734

 Summary: [SQLClient] Unused config.{sub,guess}
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 09:01:32 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

SQLClient includes config.sub and config.guess but AFAICS doesn't use them --
there's no AC_CANONICAL_* macro call in configure.ac.  There is some
CPU-specific stuff related to the JDBC bundle but GNUSTEP_* variables are used
and they're determined by GNUstep Make.

install-sh also seems unnecessary.




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42734

___
  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 #42740] Some tests inevitably fail in a chroot

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42740

 Summary: Some tests inevitably fail in a chroot
 Project: GNUstep
Submitted by: yavor
Submitted on: Sat 12 Jul 2014 02:09:54 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Tests/GNUmakefile has an obvious thinko which leads to some NSBundle tests to
fail, among others:

base/NSBundle/general.m:
Failed test:   general.m:76 ... -executablePath returns an executable path
(real bundle)
Failed test:   general.m:81 ... +bundleWithIdentifier returns correct
bundle


The second issue is when HOME is non-writable, non-existing directory.  This
test fails then:

base/Functions/NSGeometry1.m:
Failed test: NSGeometry1.m:112 ... In MacOSX geometry compat mode


In a standard sbuild/buildd environment, stdin is redirected to /dev/null and
I believe this is the reason for these tests to fail:

base/NSRunLoop/performers.m:
Failed test: performers.m:49 ...
-performSelector:target:argument:order:modes: only sends the message once
Failed test: performers.m:65 ...
-performSelector:target:argument:order:modes: orders performers correctly
Failed test: performers.m:89 ... -cancelPerformSelector:target:argument:
works

base/NSRunLoop/thread.m:
Failed test: thread.m:193 ... A loop with an input source will block


And finally, network connection is not guaranteed to be available.

Attached is a patch that addresses some of these issues.



___

File Attachments:


---
Date: Sat 12 Jul 2014 02:09:54 PM EEST  Name: testsuite-fixes.patch  Size: 2kB
  By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31705

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42740

___
  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 #42411] gdomap chroots to /tmp

[Yavor Doganov]

Follow-up Comment #2, bug #42411 (project gnustep):

I don't know either, I'll ask the original bug submitter.

 is there a debian specific standard for this which
 could be conditionally compliled when building on a
 debian system?

I don't think so.  I believe this was not caught by an automatic
security-check tool.  It's just that some people have a habit to review
daemons' code and gdomap seems to be getting a lot of attention :-)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42411

___
  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 #42423] base.make errouneously pollutes CONFIG_SYSTEM_* variables

[Yavor Doganov]

Follow-up Comment #2, bug #42423 (project gnustep):

 That change was to avoid conflicting library versions
 being linked into base and gui ... 

I see.  The way to address this problem is to take care to relink all reverse
dependencies of the library.  Which I agreee is a bit tedious and even error
prone if you install everything manually.

 I don't really know/understand the benefits of explicitly
 specifying the libraries

There is no benefit at all.  If program foo links dynamically with libA which
dynamically links with libB, there is no good reason for foo to link with libB
(unless the dynamic linker is not capable of loading the DSOs in which case
the last resort would be static linking).  Imagine if libB is being linked
with libC and libD, and libD is linked with libE...  Shared libraries are
ubiquitous nowadays so a system would easily become unmaintainable mess if one
does that.  For this reason, almost all binary-based distros delete libtool
.la files or at least empty their dependency_libs field.  The GNUstep core
libraries have been doing a great job on this front by keeping their external
library dependencies unexposed.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42423

___
  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 #42762] Large file support

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42762

 Summary: Large file support
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 13 Jul 2014 05:05:46 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

It seems that -[NSData initWithContentsOfFile:] (and +dataWithContentsOfFile:,
-initWithContentsOfMappedFile:, etc as consequence) will fail with large files
on 32bit systems.

The standard GNU way of dealing with this is to use gnulib which provides
replacements for fseeko/ftello with all possible workarounds.  Not doable
currently, so the attached patch enables such support only on systems that
have these functions available (most systems these days).

Unfortunately I was not able to test it as none of my machines has enough
memory and I get (expected) NSMallocException...



___

File Attachments:


---
Date: Sun 13 Jul 2014 05:05:46 PM EEST  Name: lfs.patch  Size: 5kB   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31707

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42762

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #4, bug #42717 (project gnustep):

As I ran out of ideas I made a binary search.  The bad commit is r34050. 
It's not easy for me to spot what's wrong, though...

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #5, bug #42717 (project gnustep):

Moving the NSTitleCell decoding at the beginning as in the attached patch
makes Cenon load with 0.24.0.  -calcSizesAllowingNegative: accesses _cell so
at first glance it looks like the correct change.  However, if I apply the
patch against trunk I get a different crash:

Program received signal SIGSEGV, Segmentation fault.
0xb753c05b in objc_msg_lookup (receiver=0x548b5a59, 
op=0xb7f392b8 _OBJC_SELECTOR_TABLE+568)
at /build/gcc-4.9-C54cEj/gcc-4.9-4.9.0/src/libobjc/sendmsg.c:448
448 /build/gcc-4.9-C54cEj/gcc-4.9-4.9.0/src/libobjc/sendmsg.c: Няма
такъв файл или директория.
(gdb) bt
#0  0xb753c05b in objc_msg_lookup (receiver=0x548b5a59, 
op=0xb7f392b8 _OBJC_SELECTOR_TABLE+568)
at /build/gcc-4.9-C54cEj/gcc-4.9-4.9.0/src/libobjc/sendmsg.c:448
#1  0xb7c12567 in -[NSMenu(GNUstepPrivate) _setGeometry] (
self=0xb7d1c173 -[NSMenu(NibCompatibility) _setMain:]+675, 
_cmd=0x8a722a0) at NSMenu.m:505
#2  0x08a722a0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


(file #31714)
___

Additional Item Attachment:

File name: nsbox.patchSize:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #7, bug #42717 (project gnustep):

I was sure I mentioned it was the Main.xib file, but apparently missed that. 
Sorry.  I tried --GNU-Debug=XIB as soon as I found out the crash happens when
loading the XIB file, but was completely lost in the data it spits.  Attached
is the compressed output with pristine (unpatched) GNUstep GUI 0.24.0.

As for Valgrind, it used to be completely unusable for GNUstep IIRC.  Haven't
touched it for ages, so if any special setup is needed I'd appreciate if you
give me some directions.

The Cenon version is 4.0.2; I see I missed mentioning that too.

(file #31715)
___

Additional Item Attachment:

File name: XIB.txt.gz Size:103 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42778] Frameworks with different SONAME cannot coexist

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42778

 Summary: Frameworks with different SONAME cannot coexist
 Project: GNUstep
Submitted by: yavor
Submitted on: Tue 15 Jul 2014 08:28:37 PM EEST
Category: Makefiles
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

There is a fundamental issue in the way GNUstep Make creates the symlinks for
the frameworks, at least with the fhs-system layout.

Suppose that you have Foo.app linked with the Bar framework, which has
interface version 0:


$ ldd /usr/bin/Foo | grep Bar
libBar.so.0 = /usr/lib/libBar.so.0 (0xb76ab000)
$ ls -l /usr/lib/libBar.so.0
/usr/lib/libBar.so.0 -
GNUstep/Frameworks/Bar.framework/Versions/Current/libBar.so.0


So far so good, and then you install a new version of Bar which is not binary
compatible and has interface version 1.  This will replace the Current
symlink to point to Versions/1 and subsequently will wipe the
/usr/lib/libBar.so.0 symlink.  Then Foo.app will fail to load because the
dynamic linker cannot find the library (it is there, in Versions/0, but the
symlink is gone):


$ ldd /usr/bin/Foo | grep Bar
libBar.so.0 = not found


Normally, Foo.app should still be working by continuing to link with
libBar.so.0 until it is rebuilt, at which point it should link with
libBar.so.1.  I am not sure if this is a problem for this layout only.




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42778

___
  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

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42782

 Summary: Crash when loading a gorm file
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 16 Jul 2014 03:22:11 PM EEST
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Yet another mysterious bug like bug#42717.  Both Vindaloo and Gorm crash on
x86 when loading the attached gorm file.  If I rebuild GUI (0.24.0) without
optimization there is no problem.  Needless to say, this worked pretty well
with old GNUstep releases.

The backtrace is completely meaningless:

Program received signal SIGSEGV, Segmentation fault.
0xbfffedca in ?? ()
(gdb) bt
#0  0xbfffedca in ?? ()
#1  0xb7a27960 in ?? () from /usr/lib/libgnustep-base.so.1.24
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Cannot be reproduced on x86_64.



___

File Attachments:


---
Date: Wed 16 Jul 2014 03:22:11 PM EEST  Name: Document.gorm.tar.gz  Size: 1kB 
 By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31728

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42782

___
  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

[Yavor Doganov]

Follow-up Comment #2, bug #42782 (project gnustep):

GNUstep Base is built with detached debugging symbols and the -dbg package is
installed.  The stack gets seriously messed up or destroyed.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42782

___
  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 #42789] [SQLClient] Two versions of the library cannot coexist peacefully

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42789

 Summary: [SQLClient] Two versions of the library cannot
coexist peacefully
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 17 Jul 2014 11:32:46 AM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Installing a new binary-incompatible SQLClient version will overwrite the
bundles.  They may still be loaded successfully by the old library but that is
not guaranteed.  This is particularly bad if the bundles are linked with the
library, as loading them from the old library will also load the new library,
leading to obvious runtime problems.

With the attached patch the two SQLClient versions are self-contained so
applications linked with either one will continue to work properly.



___

File Attachments:


---
Date: Thu 17 Jul 2014 11:32:46 AM EEST  Name: versioned-bundles.patch  Size:
2kB   By: yavor

http://savannah.gnu.org/bugs/download.php?file_id=31733

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42789

___
  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 #42804] Dubious configure test for -fexec-charset

[Yavor Doganov]

Follow-up Comment #1, bug #42804 (project gnustep):

Just another confirmation:

$ locale
LANG=en_US.ISO-8859-1
LANGUAGE=
LC_CTYPE=en_US.ISO-8859-1
LC_NUMERIC=en_US.ISO-8859-1
LC_TIME=en_US.ISO-8859-1
LC_COLLATE=en_US.ISO-8859-1
LC_MONETARY=en_US.ISO-8859-1
LC_MESSAGES=en_US.ISO-8859-1
LC_PAPER=en_US.ISO-8859-1
LC_NAME=en_US.ISO-8859-1
LC_ADDRESS=en_US.ISO-8859-1
LC_TELEPHONE=en_US.ISO-8859-1
LC_MEASUREMENT=en_US.ISO-8859-1
LC_IDENTIFICATION=en_US.ISO-8859-1
LC_ALL=en_US.ISO-8859-1
$ gcc config.constant-string-encoding.c  ./a.out; echo $?
1
$ gcc -finput-charset=ISO-8859-1 config.constant-string-encoding.c  ./a.out;
echo $?
0
$ export LANG=bg_BG.UTF-8
$ export LC_ALL=bg_BG.UTF-8
$ locale
LANG=bg_BG.UTF-8
LANGUAGE=
LC_CTYPE=bg_BG.UTF-8
LC_NUMERIC=bg_BG.UTF-8
LC_TIME=bg_BG.UTF-8
LC_COLLATE=bg_BG.UTF-8
LC_MONETARY=bg_BG.UTF-8
LC_MESSAGES=bg_BG.UTF-8
LC_PAPER=bg_BG.UTF-8
LC_NAME=bg_BG.UTF-8
LC_ADDRESS=bg_BG.UTF-8
LC_TELEPHONE=bg_BG.UTF-8
LC_MEASUREMENT=bg_BG.UTF-8
LC_IDENTIFICATION=bg_BG.UTF-8
LC_ALL=bg_BG.UTF-8
$ gcc config.constant-string-encoding.c  ./a.out; echo $?
1
$ gcc -finput-charset=ISO-8859-1 config.constant-string-encoding.c  ./a.out;
echo $?
0


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42804

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #9, bug #42717 (project gnustep):

Here's the valgrind output:

$ valgrind Cenon
==14425== Memcheck, a memory error detector
==14425== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14425== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==14425== Command: Cenon
==14425== 
==14425== Invalid read of size 4
==14425==at 0x4AD5058: objc_msg_lookup (sendmsg.c:448)
==14425==by 0x41211B8: _i_NSBox_Private_calcSizesAllowingNegative_ (in
/usr/lib/libgnustep-gui.so.0.24.0)
==14425==  Address 0xff98 is not stack'd, malloc'd or (recently) free'd
==14425== 
==14425== 
==14425== Process terminating with default action of signal 11 (SIGSEGV)
==14425==  Access not within mapped region at address 0xFF98
==14425==at 0x4AD5058: objc_msg_lookup (sendmsg.c:448)
==14425==by 0x41211B8: _i_NSBox_Private_calcSizesAllowingNegative_ (in
/usr/lib/libgnustep-gui.so.0.24.0)
==14425==  If you believe this happened as a result of a stack
==14425==  overflow in your program's main thread (unlikely but
==14425==  possible), you can try to increase the size of the
==14425==  main thread stack using the --main-stacksize= flag.
==14425==  The main thread stack size used in this run was 8388608.
==14425== 
==14425== HEAP SUMMARY:
==14425== in use at exit: 17,125,664 bytes in 378,360 blocks
==14425==   total heap usage: 647,770 allocs, 269,410 frees, 39,616,506 bytes
allocated
==14425== 
==14425== LEAK SUMMARY:
==14425==definitely lost: 34,376 bytes in 691 blocks
==14425==indirectly lost: 50,125 bytes in 3,300 blocks
==14425==  possibly lost: 14,724,851 bytes in 340,448 blocks
==14425==still reachable: 2,316,312 bytes in 33,921 blocks
==14425== suppressed: 0 bytes in 0 blocks
==14425== Rerun with --leak-check=full to see details of leaked memory
==14425== 
==14425== For counts of detected and suppressed errors, rerun with: -v
==14425== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
Нарушение на разделянето(segfault)


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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

[Yavor Doganov]

Follow-up Comment #4, bug #42782 (project gnustep):


==15741== Command: Gorm
/tmp/viewpdf.app-0.2dfsg1/English.lproj/Document.gorm/
==15741== 
2014-07-20 19:27:38.764 Gorm[15741] Tiff Error (GSTiffReadData) Not a TIFF or
MDI file, bad magic number 20039 (0x4e47)
2014-07-20 19:27:42.187 Gorm[15741] Tiff Error (GSTiffReadData) Not a TIFF or
MDI file, bad magic number 20039 (0x4e47)
==15741== Conditional jump or move depends on uninitialised value(s)
==15741==at 0x408C385: _i_GormImage__initWithData_withFileName_inWrapper_
(in /usr/lib/gorm.app/libGormCore.so.1.2.20)
==15741==by 0xB3A875F: ???
==15741== 
vex x86-IR: unhandled instruction bytes: 0xF0 0x5A 0x3A 0xB
==15741== Use of uninitialised value of size 4
==15741==at 0xB3A8762: ???
==15741== 
==15741== Invalid read of size 1
==15741==at 0xB3A8762: ???
==15741==  Address 0x134c0a52 is not stack'd, malloc'd or (recently) free'd
==15741== 
==15741== 
==15741== Process terminating with default action of signal 11 (SIGSEGV)
==15741==  Access not within mapped region at address 0x134C0A52
==15741==at 0xB3A8762: ???
==15741==  If you believe this happened as a result of a stack
==15741==  overflow in your program's main thread (unlikely but
==15741==  possible), you can try to increase the size of the
==15741==  main thread stack using the --main-stacksize= flag.
==15741==  The main thread stack size used in this run was 8388608.
==15741== 
==15741== HEAP SUMMARY:
==15741== in use at exit: 9,972,293 bytes in 71,858 blocks
==15741==   total heap usage: 1,228,610 allocs, 1,156,752 frees, 105,972,400
bytes allocated
==15741== 
==15741== LEAK SUMMARY:
==15741==definitely lost: 37,671 bytes in 1,025 blocks
==15741==indirectly lost: 62,465 bytes in 4,126 blocks
==15741==  possibly lost: 6,784,244 bytes in 27,296 blocks
==15741==still reachable: 3,087,913 bytes in 39,411 blocks
==15741== suppressed: 0 bytes in 0 blocks
==15741== Rerun with --leak-check=full to see details of leaked memory
==15741== 
==15741== For counts of detected and suppressed errors, rerun with: -v
==15741== Use --track-origins=yes to see where uninitialised values come from
==15741== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 1 from 1)
Нарушение на разделянето(segfault)


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42782

___
  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

[Yavor Doganov]

Follow-up Comment #6, bug #42782 (project gnustep):

Gorm doesn't crash now but it doesn't load the file either.  An alert panel is
shown with title Alert and No information as message.  The image file
is, oddly enough, data.info.  Here's the backtrace when this method is
reached:

Breakpoint 1, -[GormImage initWithData:withFileName:inWrapper:] (
self=0x9010440, _cmd=0xb7fae9a0 _OBJC_SELECTOR_TABLE+32, 
aData=0x81a0498, aName=0x9028d60, flag=1 ' 01') at GormImage.m:84
84[smallImage setSize: NSMakeSize(70, originalSize.height / 
ratioW)];
(gdb) po aName
data.info
(gdb) bt
#0  -[GormImage initWithData:withFileName:inWrapper:] (self=0x9010440, 
_cmd=0xb7fae9a0 _OBJC_SELECTOR_TABLE+32, aData=0x81a0498, 
aName=0x9028d60, flag=1 ' 01') at GormImage.m:84
#1  0xb7f15136 in +[GormImage imageForData:withFileName:inWrapper:] (
self=0xb7faea60 _OBJC_Class_GormImage, 
_cmd=0xb7fd9238 _OBJC_SELECTOR_TABLE+952, aData=0x81a0498, 
aName=0x9028d60, flag=1 ' 01') at GormImage.m:56
#2  0xb7f46a2b in -[GormWrapperLoader loadFileWrapper:withDocument:] (
self=0x8b1b310, _cmd=0xb2c26980 _OBJC_SELECTOR_TABLE+1216, 
wrapper=0x9082728, doc=0x8544568) at GormWrapperLoader.m:87
#3  0xb2c1fd2f in -[GormGormWrapperLoader loadFileWrapper:withDocument:] (
self=0x8b1b310, _cmd=0xb7fa4208 _OBJC_SELECTOR_TABLE+3336, 
wrapper=0x9082728, doc=0x8544568) at GormGormWrapperLoader.m:361
#4  0xb7f071eb in -[GormDocument loadFileWrapperRepresentation:ofType:] (
self=0x8544568, _cmd=0xb7dc22b8 _OBJC_SELECTOR_TABLE+696, 
wrapper=0x9082728, type=0x8143480) at GormDocument.m:3373
#5  0xb7a7782f in -[NSDocument readFromFileWrapper:ofType:error:] (
self=0x8544568, _cmd=0xb7dc22d0 _OBJC_SELECTOR_TABLE+720, 
wrapper=0x9082728, type=0x8143480, error=0xb53c) at NSDocument.m:723
#6  0xb7a77768 in -[NSDocument readFromURL:ofType:error:] (self=0x8544568, 
_cmd=0xb7dc20b8 _OBJC_SELECTOR_TABLE+184, url=0x9082728, type=0x8143480,

error=0xb53c) at NSDocument.m:757
#7  0xb7a78d41 in -[NSDocument initForURL:withContentsOfURL:ofType:error:] (
self=0x8544568, _cmd=0xb7dc2108 _OBJC_SELECTOR_TABLE+264, 
forUrl=0x99d4120, url=0x99d4120, type=0x8143480, error=0xb53c)
at NSDocument.m:163
#8  0xb7a78bf5 in -[NSDocument initWithContentsOfURL:ofType:error:] (
self=0x8544568, _cmd=0xb7dc4800 _OBJC_SELECTOR_TABLE+384, url=0x99d4120,

type=0x8143480, error=0xb53c) at NSDocument.m:189
#9  0xb7a7d222 in -[NSDocumentController
makeDocumentWithContentsOfURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc48d8
_OBJC_SELECTOR_TABLE+600, 
url=0x99d4120, type=0x8143480, err=0xb53c)
at NSDocumentController.m:446
#10 0xb7a7c76c in -[NSDocumentController
openDocumentWithContentsOfURL:display:error:] (self=0x8831348, _cmd=0xb7e5a688
_OBJC_SELECTOR_TABLE+520, 
url=0x99d4120, flag=1 ' 01', err=0xb53c) at
NSDocumentController.m:690
#11 0xb7ba748f in -[GSServicesManager application:openFile:] (self=0x81ca890,

_cmd=0xb7e5a6b0 _OBJC_SELECTOR_TABLE+560, theApp=0x81f6ee8, 
file=0x811b3c8) at GSServicesManager.m:589
#12 0xb7ba7354 in -[GSServicesManager application:openFiles:] (self=0x81ca890,

_cmd=0xb7d93128 _OBJC_SELECTOR_TABLE+1960, theApp=0x81f6ee8, 
files=0x816e008) at GSServicesManager.m:617
#13 0xb7a14c31 in -[NSApplication finishLaunching] (self=0x81f6ee8, 
_cmd=0xb7d93218 _OBJC_SELECTOR_TABLE+2200) at NSApplication.m:1126
#14 0xb7a1886d in -[NSApplication run] (self=0x81f6ee8, 
_cmd=0xb7d89408 _OBJC_SELECTOR_TABLE+904) at NSApplication.m:1538
#15 0xb79fa9bb in NSApplicationMain (argc=2, argv=0xb754) at
Functions.m:91
#16 0x08049327 in main (argc=2, argv=0xb754) at main.m:30


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42782

___
  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 #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #11, bug #42717 (project gnustep):

No crash if I apply your changes in r38003.

If it is a compiler bug, most probably it is present in earlier versions as
this bug was reported last year when 4.9 was not released yet.  However, it
may be that GCC is taking advantage of the undefined behaviour scenario and
is optimizing in a way that leads to a crash.  Very often code that works with
-O0 but fails with -O2 reveals a bug in the code, not the compiler.  In any
case, if it is a compiler bug, it should be haunted down and fixed rather than
the code adapted to cope with it.  IMHO.  It might be difficult to write a
self-contained example exposing the bug, though.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42717

___
  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 #42778] Frameworks with different SONAME cannot coexist

[Yavor Doganov]

Follow-up Comment #1, bug #42778 (project gnustep):

Actually, it is even more serious than that.  Installing a new version of the
framework will wipe out the old one completely, so there will only be one
Version, with Current pointing to it.  This is done unconditionally as the
first command of the internal_framework_install_ recipe.  The current behavior
defeats the whole idea of frameworks (not that I ever understood what
frameworks are for in the first place).

What I wrote in the first message (that the old libBar is still in Versions/0)
is true when the framework is packaged as it is installed in a tmp dir during
build and there's no previous framework version to delete there.

Steps to reproduce (with a random GNUstep framework):

$ make
$ make install DESTDIR=/tmp/foo
$ make clean
$ make install INTERFACE_VERSION=5 DESTDIR=/tmp/foo

And the shocking result:

$ ls -l /tmp/foo/usr/lib/
общо 20
drwxr-xr-x 3 yavor yavor 4096 юли 21 19:01 GNUstep
lrwxrwxrwx 1 yavor yavor   67 юли 21 19:02 libRSSKit.so -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   69 юли 21 19:01 libRSSKit.so.0 -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor   71 юли 21 19:02 libRSSKit.so.0.4 -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.0.4
lrwxrwxrwx 1 yavor yavor   69 юли 21 19:02 libRSSKit.so.5 -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.5

libRSSKit.so.0 is a broken symlink.  As a result applications that linked with
RSSKit cannot be started.

$ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/
общо 4
drwxr-xr-x 4 yavor yavor 4096 юли 21 19:02 5
lrwxrwxrwx 1 yavor yavor1 юли 21 19:02 Current - 5

There should be a 0 directory there with the old library.

Would you accept a patch that stops deleting the installed framework and also
creates symlinks directly to Versions/$ver instead of Versions/Current?  The
.so symlink must probably still point to Current for projects linking with an
internal framework to continue to work.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42778

___
  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

[Yavor Doganov]

Follow-up Comment #8, bug #42782 (project gnustep):

Yes, the info type is there and the array is quite large:

(gdb) po [NSImage imageFileTypes]
(tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns, 3fr, a, aai, ai, art, arw,
avi, avs, b, bgr, bgra, bie, bmp, bmp2, bmp3, brf, c, cal, cals, canvas,
caption, cin, cip, clip, cmyk, cmyka, cr2, crw, cur, cut, dcm, dcr, dcx, dds,
dfont, djvu, dng, dot, dpx, epdf, epi, eps, eps2, eps3, epsf, epsi, ept, ept2,
ept3, erf, exr, fax, fits, fractal, fts, g, g3, gif87, gradient, gray, group4,
hald, hdr, histogram, hrz, htm, html, icb, ico, icon, info, inline, ipl,
isobrl, j2c, j2k, jbg, jbig, jng, jp2, jpc, jpx, k, k25, kdc, label, m, m2v,
m4v, mac, map, mat, matte, mef, miff, mng, mono, mov, mp4, mpc, mpeg, mpg,
mrw, msl, msvg, mtv, mvg, nef, nrw, null, o, orf, otb, otf, pal, palm, pam,
pango, pattern, pbm, pcd, pcds, pcl, pct, pcx, pdb, pdf, pdfa, pef, pes, pfa,
pfb, pfm, pgm, pgx, picon, pict, pix, pjpeg, plasma, png24, png32, png8,
preview, ps, ps2, ps3, psb, psd, ptif, pwp, r, radial-gradient, raf, ras,
rgb, rgba, rgbo, rla, rle, scr, sct, sfw, sgi, shtml, sr2, srf, stegano, sun,
svg, svgz, text, tga, thumbnail, tiff64, tile, tim, ttc, ttf, txt, ubrl, uil,
uyvy, vda, vicar, vid, viff, vst, wbmp, wmf, wmv, wmz, wpg, x, x3f, xbm, xc,
xcf, xpm, xps, xv, xwd, y, ycbcr, ycbcra, yuv)


Apparently these extra types come from GSImageMagickImageRep; I get them on
amd64 too.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42782

___
  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

[Yavor Doganov]

Follow-up Comment #9, bug #42782 (project gnustep):

FYI, the bug is reproducible if I rebuild GUI with --disable-imagemagick (the
image file types are just tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns in
that case).  The gdb backtrace is meaningless again and the valgrind output
is:

==8543== Command: Gorm ./English.lproj/Document.gorm/
==8543== 
vex x86-IR: unhandled instruction bytes: 0x6D 0x7 0x8 0xC7
==8543== Invalid write of size 1
==8543==at 0xBEB7BF4A: ???
==8543==  Address 0x75b99204 is not stack'd, malloc'd or (recently) free'd
==8543== 
==8543== 
==8543== Process terminating with default action of signal 11 (SIGSEGV)
==8543==  Access not within mapped region at address 0x75B99204
==8543==at 0xBEB7BF4A: ???


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?42782

___
  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

[Yavor Doganov]

Follow-up Comment #11, bug #42782 (project gnustep):

Yes, I used Gorm 1.2.20 + your latest changes.  Most probably it is not an
issue with Gorm at all.

I'd really wish to provide more information...  Perhaps I could put
breakpoints at some places and step through from there, this would at least
give you some clue, as blurry as that may be.  As Gorm is a fairly complex
program, I'm trying Vindaloo first.  I already figured out that Vindaloo
crashes in -[Document -makeWindowControllers], right after [self
addWindowController: ctrl]; ctrl is initalized properly with
-initWithWindowNibName: with [self windowNibName] as argument (which returns
@Document).  Stepping from there:

(gdb) n
-[NSDocumentController openDocumentWithContentsOfURL:display:error:] (
self=0x840c0a8, _cmd=0xb7f73648 _OBJC_SELECTOR_TABLE+520, url=0x840ae20,

flag=1 ' 01', err=0xb4cc) at NSDocumentController.m:708
708   [self noteNewRecentDocument: document];
(gdb) n
710   if (flag  [self shouldCreateUI])
(gdb) n
712   [document showWindows];
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()


Putting breakpoints further:

Breakpoint 2, -[NSDocument showWindows] (self=0x82a1268, 
_cmd=0xb7edd828 _OBJC_SELECTOR_TABLE+488) at NSDocument.m:415
415 {
(gdb) po _window_controllers 
(Controller: 0x83e54f8)
(gdb) n
417   withObject: self];
(gdb) n
416   [_window_controllers makeObjectsPerformSelector: 
@selector(showWindow:)
(gdb) n
417   withObject: self];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()

Breakpoint 3, -[NSWindowController showWindow:] (
self=0xb7edb1b8 _OBJC_SELECTOR_TABLE+504, 
_cmd=0xb7edb1b8 _OBJC_SELECTOR_TABLE+504, sender=0x81fdb90)
at NSWindowController.m:394
394 {
(gdb) n
395   NSWindow *window = [self window];
(gdb) po self
Controller: 0x83e73e8
(gdb) po [self window]

Program received signal SIGSEGV, Segmentation fault.
0xbfffef6a in ?? ()

Breakpoint 4, -[NSWindowController window] (self=0x83ea168, 
_cmd=0xb7f680f0 _OBJC_SELECTOR_TABLE+176) at NSWindowController.m:297
297 {
(gdb) n
298   if (_window == nil  ![self isWindowLoaded])
(gdb) n
308   [self windowWillLoad];
(gdb) p _window
$5 = (struct NSWindow *) 0x0
(gdb) n
309   if (_owner != self 
(gdb) po self
Controller: 0x83ea168
(gdb) po _owner
Controller: 0x83ea168
(gdb) n
315   [self loadWindow];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.

Breakpoint 5, -[NSWindowController loadWindow] (self=0x83e5340, 
_cmd=0xb7f68170 _OBJC_SELECTOR_TABLE+304) at NSWindowController.m:476
476 {
(gdb) n
479   if ([self isWindowLoaded]) 
(gdb) n
484   table = [NSDictionary dictionaryWithObject: _owner forKey: 
NSNibOwner];
(gdb) po table
value has been optimized out
(gdb) n
485   if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) po self
Controller: 0x83e5340
(gdb) po [self windowNibPath]
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po _owner
Controller: 0x83e5340
(gdb) n
487 withZone: [_owner zone]])
(gdb) n
485   if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) n
487 withZone: [_owner zone]])
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()

Breakpoint 6, +[NSBundle(NSBundleAdditions)
loadNibFile:externalNameTable:withZone:] (self=0xb79d43e0
_OBJC_Class_NSBundle, 
_cmd=0xb7f68250 _OBJC_SELECTOR_TABLE+528, fileName=0x8268c18, 
context=0x8267fe0, zone=0xb7a3f0c0 default_zone)
at NSBundleAdditions.m:234
234 {
(gdb) n
235   NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) po fileName
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po [NSURL fileURLWithPath: fileName]
file://localhost/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm/
(gdb) po context
{NSOwner = Controller: 0x83e5568; }
(gdb) n
237 withZone: zone];
(gdb) po nib
value has been optimized out
(gdb) n
235   NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) n
239   RELEASE(nib);
(gdb) n
235   NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) n
237 withZone: zone];
(gdb) n
236   BOOL loaded = [nib instantiateNibWithExternalNameTable: context
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()

Breakpoint 7, -[NSNib instantiateNibWithExternalNameTable:withZone:] (
self=0x8411090, _cmd=0xb7ebc0d0 _OBJC_SELECTOR_TABLE+208, 
externalNameTable=0x8410c28, zone=0xb7a3f0c0 default_zone) at
NSNib.m:152
152