bugGNUstep - Bugs: bug #48348, gnustep-config doesn't do what I...

Group
 
 

bug #48348: gnustep-config doesn't do what I want

Submitter:  Stef <stefanbidi>
Submitted:  Wed 29 Jun 2016 11:49:36 PM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 27 Oct 2020 12:26:00 PM UTC, comment #7: 

I am closing this as work seems to have been done and there hasn't been an issue since.  Please open a bug in the appropriate place on github.com if this is still an issue. GC

Gregory John Casamento <gcasa>
Group administrator
Fri 08 Jul 2016 01:12:14 PM UTC, comment #6: 

A first iteration is now available in GNUstep make:

  • GNUstep.sh sets PKG_CONFIG_PATH for all installation domains
  • in makefiles for libraries and frameworks, you can use $(GNUSTEP_INSTANCE)_PKGCONFIG_FILES to specify the files to install
Niels Grewe <thebeing>
Group Member
Thu 07 Jul 2016 09:17:41 AM UTC, comment #5: 

That looks like a good start! Getting gnustep-make to install pkgconfig files in the correct place shouldn't be too hard. In theory it would be nice to have them generated by  gnustep-make as well. That would take away the hassle with the installation domains and such.  Unfortunately that would require gnustep-make to have a better model of the code that it is building (e.g. public vs. private cflags, dependencies, etc.)

But we can start with the simple thing.

Niels Grewe <thebeing>
Group Member
Wed 06 Jul 2016 10:58:34 PM UTC, comment #4: 

Providing a pkg-config file could work, but it does have to make a few assumptions. See the attached patch for what I came up with. It currently doesn't install because it would require a patch to GNUstep-make, too. In particular, GNUstep would need to identify when installing to the fhs filesystem layout in order to put this file in a location searched for pkg-config (ie the output of "pkg-config --variable pc_path pkg-config"). If not, GNUstep.sh would need to also define $PKG_CONFIG_PATH.

Seems like a reasonable solution, but pkg-config hard-codes where libraries and such go and GNUstep-make does not. GNUstep-make always checks GNUstep.conf for were to install and look for libraries, something the .pc file will never be able to do because pkg-config does not have this type of functionality.

(file #37741)

Stef <stefanbidi>
Group Member
Sun 03 Jul 2016 08:01:21 PM UTC, comment #3: 

I think I share Stefan sentiments here. I needed to jump through hoops at least twice when trying to integrate GNUstep stuff into a non-gnumake build process (specifically CMake and Rust's gcc-rs build helper) and ended up either mangling the output of gnustep-config or just hardcoding things for a quick and dirty solution. Thinking about it, I've come to believe that maybe we don't want to use gnustep-config for this at all. Instead, it might be preferable to have the GNUstep libraries to install pkg-config files for themselves. I'd be willing to look into, but only if I don't end up being the only person using it ;-)

Niels Grewe <thebeing>
Group Member
Fri 01 Jul 2016 04:16:55 PM UTC, comment #2: 

While I see your point, that goes completely against established conventions for *-config scripts.

I tested various config scripts (freetype-config, icu-config, xml2-config and pkg-config, to name a few). The convention is that flags-type arguments output -I and -D directives, and libs-type arguments output -L and -l directives. This makes sense, because most folks just want to know where to find the headers and library, and how to link to the library.

I think we should be able to do "$ gcc $OBJCFLAGS $LIBS `gnustep-config --objc-flags --base-libs` main.m" to build a simple tool, just like I can do "$ gcc $CFLAGS $LIBS `xml2-config --cflags --libs` main.c", without having the output of gnustep-config interfere with $OBJCFLAGS and $LIBS already in place. This is the simplest possible example I could come up with.

Stef <stefanbidi>
Group Member
Thu 30 Jun 2016 07:25:29 AM UTC, comment #1: 

gnustep-config was written as a quick solution to provide an easy way to locate gnustep-make and the rest of the gnustep installation, and also to expose some of the internals of gnustep-make and to allow building/installation of simple cases in the same way that gnustep-make would do it (eg when you just want to build using a shell script rather than writing a make file).

So if/when you want to do things a different way (eg link using the linker directly  rather than via the compiler), it's going to be suboptimal and require extra work (eg a need to filter the compiler options out).  Also, of course it provides a load of stuff you don't happen to want, but other people do.

That being said, it's close enough to the functionality you are expecting, that I can imagine how frustrating it must be to find it actually does something different, and I know that there are other people who might want similar facilities to the ones you want (generally everyone wants something slightly different, but there's a lot of commonality too).

I think patches to improve this state would be very welcome:

1. change the documentation of the script to make it clearer what each option does

2. add new options to do the things that you specifically want (this may require you to change gnustep-make internals. (in your example it sounds like we would want to hold compiler link options and linker link options in separate variables rather than a single variable).

3. even rename existing options (though this would need to involve adding the new name of the option, deprecating the old one, and then removing support for the old version in successive releases ... allowing people time to change their code).


Richard Frith-Macdonald <CaS>
Group Member
Wed 29 Jun 2016 11:49:36 PM UTC, original submission:  

I was trying to use gnustep-config to link a program of mine (instead of using GNUstep-make) and ran into a major bug: gnustep-config makes a few assumptions that aren't true.

My understand of how *-config programs work is flags/cflags go to the compiler and libs go to the linker. However, gnustep-config not only exposes private flags/libs but also --objc-libs and --base-libs includes options that are not accepted by the ld linker (I guess it assumes you're using $(CC) as a linker).

Example 1, output:
$ gnustep-config --objc-flags
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fgnu-runtime -fconstant-string-class=NSConstantString -I. -I/home/user/GNUstep/Library/Headers -I/usr/include

In this example, the following should not be part of the output: (1) -MMD and -MP; (2) -fPIC (private-use-only, I decide if this flag applies to my application); (3) -Wall (private-use-only, I should decide what warnings I want to see); (4) -pthread (not application to CFLAGS, -lpthread should be passed to linker instead); (5) -g -O2 (private-use-only, I decide the optimization level and if I want debug symbols); (6) -I. (I don't understand why this is even here).

Expected output: -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN -DGSDIAGNOSE -fno-strict-aliasing -fgnu-runtime -fconstant-string-class=NSConstantString -I/usr/include

Example 2, output:
$ gnustep-config --objc-libs
-rdynamic -shared-libgcc -pthread -fgnu-runtime -L/home/user/GNUstep/Library/Libraries -L/usr/lib -lobjc -lm

Expected output: -L/usr/lib -lobjc

In this example, the following should not be part of the output:
(1) -rdynamic (private-use-only and not recognized by the linker, ld); (2) -shared-libgcc (private-use-only and also not recognized by ld); (3) -pthread (private-use-only, and ld doesn't recognize); (4) -fgnu-runtime (ld does not recognize); (5) -lm (private-use-only, my application might not need this.

Stef <stefanbidi>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #37741:  gnustep-base.pc.diff added by stefanbidi (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by FredKiefer (Updated the item)
  • -email is unavailable- added by thebeing (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by stefanbidi (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-27 gcasa Open/ClosedOpen Closed
    2017-08-24 FredKiefer CategoryNone Makefiles
    2016-07-06 stefanbidi Attached File- Added gnustep-base.pc.diff, #37741
    2016-06-30 CaS Summarygnustep-config output is unusable gnustep-config doesn't do what I want

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code