Ticket #235 (closed bug: fixed)

Opened 5 years ago

Last modified 5 years ago

pkg-config *_FLAGS not merged into argument list for compiler

Reported by: wagi Assigned to: arnonym
Priority: minor Milestone: FFADO 2.0
Component: Version: FFADO SVN (2.0 branch)
Keywords: Cc:
The device the bug applies to:


I need to do something like this to get the branch compiled:

Index: SConstruct
--- SConstruct  (revision 1673)
+++ SConstruct  (working copy)
@@ -215,7 +215,10 @@

        for pkg in pkgs:
                name2 = pkg.replace("+","").replace(".","").replace("-","").upper()
-               env['%s_FLAGS' % name2] = conf.GetPKGFlags( pkg, pkgs[pkg] )
+               env['%s_FLAGS' % name2] = " " + conf.GetPKGFlags( pkg, pkgs[pkg] ).strip() + " "
+               print '%s_FLAGS' % name2
+               print env['%s_FLAGS' % name2]
+               env.Append(CPPFLAGS = env['%s_FLAGS' % name2])
                if env['%s_FLAGS'%name2] == 0:
                        allpresent &= 0

If I understand it correctly the problem is that "env['%s_FLAGS' % name2]" doesn't work for my system. Somehow all those _FLAGS should be merge into CFLAGS or whatever.

Change History

09/22/09 14:32:52 changed by arnonym

  • owner set to arnonym.
  • status changed from new to assigned.

If the string-arguments don't work for keys of maps, something is strange. Which version of python and scons are you using? (Here I use python 2.6, I don't think scons or our configs are python 3 compatible...)

Appending manually to CPPFLAGS is wrong as its error-prone. Half the flags returned are linker-flags, not compiler-flags. So at least we should let env.MergeFlags? do its job.

But even that is wrong here. We don't want to link everything to all requisites. libffado.so doesn't need to link to dbus or alsa... The flags only get merged into the argument list per target, that is in the subdirs...

09/22/09 21:40:47 changed by wagi

I have a Fedora 11 x86_64 system here.

$ python --version
Python 2.6

$ rpm -qa | grep python-2.6

$ scons --version
SCons by Steven Knight et al.:
        script: v1.2.0.r3842, 2008/12/20 22:59:52, by scons on scons-dev
        engine: v1.2.0.r3842, 2008/12/20 22:59:52, by scons on scons-dev
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation

I agree, the CPPFLAGS things was just a hack to get it working. This is for sure not the correct thing to do

10/01/09 13:54:40 changed by arnonym

I am still unsure on what the problem here is.

I do have the very same versions of scons and python and here it works perfectly for x86 and x86_64.

Are you sure you have a clean, up to date checkout without any other changes?

10/01/09 23:37:53 changed by wagi

I have a clean checkout from today. It has the same problem. The FLAGS from pkgconfig are not merged into the command line for g++.

Maybe it has something to do that I don't use 'standard' installation paths, e.g /home/wagi/local/. IMO that should not matter.

10/02/09 00:08:07 changed by arnonym

I too install to ~/ and ffado also correctly gets the right paths from my custom jack install.

So what is the problem?

  • Are the flags returned by the pkg-config-helpers the same as returned on the commandline?
  • Are the flags not propagated to the sub-sconscripts?
  • Are the correct flags parsed in an incorrect way?

What about an irc session?

10/08/09 05:08:07 changed by wagi

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [1677]) Merge flags into the construction variables. This fixes #235

10/08/09 06:19:46 changed by arnonym

  • status changed from closed to reopened.
  • resolution deleted.

No! This doesn't fix it. It just circumvents a problem only you seem to have. And it links every dependency to every app/lib which afaik isn't necessary nor wanted.

Please let us fix this the real way. I will be online in irc this evening.

10/08/09 06:26:12 changed by arnonym

Even worse this links libffado to dbus for example. Try explaining that to fons adriansen...

10/08/09 06:53:53 changed by arnonym

(In [1678]) The test tools don't need libdbus linked, libffado doesn't need libdbus linked. In short: Every app/lib gets to make its own decision what is linked. Thats why these flags are added as variables to the global environment. Which in turn is handed to the subdirs SConscripts...

see #235

10/08/09 07:16:33 changed by wagi

The include flags itself do not introduce dependency. This is still up to the coder which includes certain headers or not. My question is where in the SConscript can I tell which files have which dependencies.

BTW: I debugged for a while and the problem is just there is *no* place in the SConscript where this merging is happening. I really hope there is no scons magic involved.

10/08/09 07:28:32 changed by wagi

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [1679]) Add libraw1394 dependency to dbus control since it depends on it (ffado-dbus-server.cpp:#include fbtypes.h -> libraw1394). Fixes #235 for real.