[bug #42650] Tools are linked with unnecessary libraries
Update of bug #42650 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Patch applied .. thanks. ___ 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 #42423] base.make errouneously pollutes CONFIG_SYSTEM_* variables
Update of bug #42423 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: That change was to avoid conflicting library versions being linked into base and gui ... but I guess easing building in a sandbox for packaging is more important. Beyond that, I don't really know/understand the benefits of explicitly specifying the libraries, so I'll trust your opinion ... at least until/unless others complain. Thanks. ___ 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 #42693] Fix build on mips64(el) with GCC
Update of bug #42693 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks, I applied that patch ___ 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 #42740] Some tests inevitably fail in a chroot
Update of bug #42740 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks .,.. I applied that patch. ___ 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
Follow-up Comment #1, bug #42411 (project gnustep): I don't mind making things even more paranoid, but I don't know of an empty, non-writable directory that the program can reliably move to, and creating a directory which could then not be cleaned up on program termination (because the program is chrooted inside it) does not seem an acceptable option. Is there a standard portable way to do this (a quick internet search didn't reveal anything to me)? Failing that, is there a debian specific standard for this which could be conditionally compliled when building on a debian system? ___ 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 #42734] [SQLClient] Unused config.{sub,guess}
Update of bug #42734 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ... extraneous files removed from svn ___ 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 #41628] NSJSONSerialization segfaults when deserializing from file-based NSStream
Update of bug #41628 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: Added that fix, thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?41628 ___ 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
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
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
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
