Ticket #156 (closed bug: wontfix)

Opened 3 years ago

Last modified 2 years ago

build on sparc fails due to missing -fPIC in external/libconfig

Reported by: sobukus Assigned to: ppalmers
Priority: minor Milestone: FFADO 2.1
Component: Version: FFADO 2.0-beta6 (1.999.36)
Keywords: Cc:
The device the bug applies to:

Description

Build of http://subversion.ffado.org/ffado/branches/libffado-2.0 on (rev 1319) x86-64 with PIC enabled in CFLAGS fails with this:

gcc -o external/libconfig/grammar.o -c -DDEBUG -Wall -g -m64 -DDEBUG -Wall -g -DDBUS_HAS_THREADS_INIT_DEFAULT -m64 -Iexternal/libconfig external/libconfig/grammar.c gcc -o external/libconfig/libconfig.o -c -DDEBUG -Wall -g -m64 -DDEBUG -Wall -g -DDBUS_HAS_THREADS_INIT_DEFAULT -m64 -Iexternal/libconfig external/libconfig/libconfig.c g++ -o external/libconfig/libconfigcpp.o -c -DDEBUG -Wall -g -DDBUS_HAS_THREADS_INIT_DEFAULT -m64 -Iexternal/libconfig external/libconfig/libconfigcpp.cpp gcc -o external/libconfig/scanner.o -c -DDEBUG -Wall -g -m64 -DDEBUG -Wall -g -DDBUS_HAS_THREADS_INIT_DEFAULT -m64 -Iexternal/libconfig external/libconfig/scanner.c scanner.c:1527: warning: 'input' defined but not used ar rc external/libconfig/libconfigpp.a external/libconfig/grammar.o external/libconfig/libconfig.o external/libconfig/libconfigcpp.o external/libconfig/scanner.o ranlib external/libconfig/libconfigpp.a g++ -o src/libffado.so -shared [ lots of objects ] -Lexternal/libconfig -lconfigpp [ lots of libs ] /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: external/libconfig/libconfigpp.a(libconfigcpp.o): relocation R_X86_64_32S against `vtable for libconfig::SettingException?' can not be used when making a shared object; recompile with -fPIC external/libconfig/libconfigpp.a: could not read symbols: Bad value collect2: ld returned 1 exit status scons: *** [src/libffado.so] Error 1 scons: building terminated because of errors.

! Problem Detected !

The trouble originates in the build of external/libconfig/libconfigpp.a as a static library and then trying to incorporate that into a shared library. SCons disables the -fPIC flag (which is included in environment CFLAGS) for the build of a static library. When I hack the corresponding SCons config file in external/libconfig to force -fPIC on CFLAGS the build completes fine. Something like that in external/libconfig/SConscript:

env.AppendUnique?( CCFLAGS=-fPIC? )

This may not be needed on x86, but it is for x86-64 where you should always compile with PIC (this will apply to alpha arch, too, most probably -- yes I still have such a thing and playfully think about trying firewire with it;-).

So, is there a clean way to just make SCons honour the given -fPIC in CFLAGS, even for the static library (that is going to be part of a dynamic library)? Otherwise I'll have to hack our (Source Mage GNU/Linux) build scripts to patch in the -fPIC for external/libconfig/libconfigpp.a in case we build for a x86-64 box.

Attachments

scons-libconfig.patch (483 bytes) - added by adi on 09/09/08 03:53:24.
Proposed patch fixing amd64

Change History

09/09/08 03:53:24 changed by adi

  • attachment scons-libconfig.patch added.

Proposed patch fixing amd64

09/09/08 03:57:36 changed by adi

  • priority changed from major to blocker.

I'm neither common with scons nor have I tested the patch on x86. It's probably "cleaner" to unconditionally append "-fPIC" to CFLAGS (like CFLAGS+="-fPIC" with make), but for such a little library, I could live with the repeated AppendUnique? line.

I also raised priority to blocker, since I expect the release to build on amd64.

09/09/08 06:11:15 changed by sobukus

Hm, is one able to compile libffado statically? In that case, you don't need PIC. Also, on x86 you can choose if you want PIC or not with shared libs... at least for my use case the best solution would actually be to simply honour the given CFLAGS in environment. They always contain -fPIC for x86-64 builds (here), and scons stripped that for the static lib. If one can avoid that stripping...

09/23/08 01:29:04 changed by ppalmers

(In [1329]) re #156: should fix the build issue on x64

09/23/08 01:29:26 changed by ppalmers

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

09/23/08 02:07:49 changed by sobukus

Questions:

1. Isn't it problematic that on x86 the main portions of the code for the shared library are compiled with -fPIC anyway, and then combined with a temporary static library that has no PIC? It seems to bail out only on systems where you really _need_ PIC, but isn't it bad in any way?

2. This fix is a specific hack for x86-64. Now I am that crazy person who wants to build ffado on Alpha -- and I really did it. It is the same situation with PIC there. Therefore...

3. My source-based distribution always adds PIC to CFLAGS/CXXFLAGS on architectures that need it. Is it possible to make scons use the environment variables? Speaking from experience with certain software packages, it really helps portability to have less specific code in the build system and at least the possibility to influence the build configuriation (p.ex. compiler flags).

09/23/08 02:32:14 changed by ppalmers

(In [1334]) re #156: detect -fPIC from OS CFLAGS/CCFLAGS

09/23/08 03:14:25 changed by sobukus

Hey, that's quick! I'll test that once I get home (both on alpha and x86-64). Also... now I see how you get OS flags into SConscript ... leading to the next point of leaving my -mcpu=ev67 intact on the alpha; or the -march=pentium-m on my laptop. Basically, I think I'm gonna make a patch to support the option of including / using the full set of OS CFLAGS; but that does not matter for this bug. I'll see if plain libffado now compiles on my x86-64 system and then I'll consider this one fixed.

09/23/08 07:34:22 changed by ppalmers

I'm not very sure that importing all the OS CFLAGS is a good idea, especially not for cross-compiling. There are some reasons why scons does not import them by default. But I don't remember what that was.

09/23/08 08:23:19 changed by sobukus

Well, I knew you would say something along that;-) Because of that, I wrote "support the option" ... when I know what to do, especially with cross-compiling, I want the freedom to decide about the correct compiler and correct compiler flags. I do not want to force this as default behaviour of ffado build (although usage of environment CFLAGS is quite common elsewhere), just an option USE_OS_FLAGS=yes would be perfectly fine for my distribution's build scripts -- because we already care about that stuff centrally. I think that this flexibility won't hurt anyone...

09/24/08 00:19:27 changed by sobukus

Hm, it built on x86-64 for me; but on Alpha it still failes because of, spefifically, external/libconfig/libconfigcpp.c is compiled without -fPIC . This file has slightly different flags anyway... but on x86-64 these still include -fPIC.

Well, strictly speaking, the original bug is fixed... I'm still puzzled by the build system.

10/19/08 03:21:53 changed by ppalmers

  • priority changed from blocker to minor.
  • milestone changed from FFADO 2.0 to FFADO 2.1.

I suggest we postpone the fix for this to 2.1 since sparc is not really the main target architecture.

09/22/09 14:57:43 changed by arnonym

  • summary changed from build on x86-64 fails due to missing -fPIC in external/libconfig to build on sparc fails due to missing -fPIC in external/libconfig.

07/21/10 10:33:31 changed by adi

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

Given the lack of manpower, we should lower our pressure and entirely forget about external/libconfig. We simply expect this library to be present by applying #290.