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


You are not allowed to post comments on this tracker with your current authentification level.

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

Submitted by:  Stef <stefanbidi>
Submitted on:  Wed Jun 29 23:49:36 2016  
Category: NoneSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

(Jump to the original submission Jump to the original submission)

Fri Jul 8 13:12:14 2016, 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>
Project Member
Thu Jul 7 09:17:41 2016, 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>
Project Member
Wed Jul 6 22:58:34 2016, 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>
Project Member
Sun Jul 3 20:01:21 2016, 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>
Project Member
Fri Jul 1 16:16:55 2016, 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>
Project Member
Thu Jun 30 07:25:29 2016, 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>
Project Member
Wed Jun 29 23:49:36 2016, 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>
Project Member


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


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by thebeing (Posted a comment)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by stefanbidi (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Jul 6 22:58:34 2016stefanbidiAttached File-=>Added gnustep-base.pc.diff, #37741
    Thu Jun 30 07:25:29 2016CaSSummarygnustep-config output is unusable=>gnustep-config doesn't do what I want

    Back to the top

    Powered by Savane 3.1-cleanup1