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