On 01/20/2014 02:49 AM, Slávek Banko wrote:

On Monday 20 of January 2014 09:25:55 David C. Rankin wrote:

...

On 01/20/2014 02:07 AM, David C. Rankin wrote:

...

All,

I do not know what in the heck this error is:

[ 95%] Built target ksysguardd-static Scanning dependencies of target ksysguardd [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/Command.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/conf.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/ksysguardd.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/PWUIDCache.c.o make[2]: *** No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a', needed by 'ksysguard/ksysguardd/ksysguardd'. Stop. CMakeFiles/Makefile2:24311: recipe for target 'ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/all' failed make[1]: *** [ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/all] Error 2 Makefile:116: recipe for target 'all' failed make: *** [all] Error 2

The base error is:

*** No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a', needed by 'ksysguard/ksysguardd/ksysguardd'. Stop.

Is this a CMake error or some other type of error? Where to start?

The failure comes from ksysguard/ksysguardd/CMakeLists.txt

#### ksysguardd (executable) ###################

tde_add_executable( ksysguardd AUTOMOC SOURCES Command.c conf.c ksysguardd.c PWUIDCache.c LINK ccont-static ksysguardd-static ${TDE_LIB_DIR}/libtdefakes_nonpic.a ${SENSORS_LIBRARIES} DESTINATION ${BIN_INSTALL_DIR} )

I suspect that should be libtdefakes_nonpic.la

will patch and test (who pushed this stuff....:-)

I do not think so. Library libtdefakes_nonpic.a arises in tdelibs (tdecore) and is designed for static linking.

Slavek

Maybe, but I built this without HAL and there is no libtdefakes_nonpic.a at all on my system only libtdefakes.al, and substituting libtdefakes.so was fine with the linker :-)

It is an automess...

On 01/20/2014 11:25 AM, Slávek Banko wrote:

How did you come to the conclusion that building ksysguardd depends on WITH_SENSORS? I do not see any such condition in CMake files.

(1) Because ksysguard is the wonderful monitoring package; (2) that uses system hardware sensors; (3) I've never run into this missing file before; and (4) this was the first time I have ever built WITH_SENSORS.

Elementary my dear Mr. Watson...

Oh,

Also, in the CMakeLists.txt file where I had to fix this screwy filename, I found this....

##### ksysguardd (executable) ###################

tde_add_executable( ksysguardd AUTOMOC SOURCES Command.c conf.c ksysguardd.c PWUIDCache.c LINK ccont-static ksysguardd-static ${TDE_LIB_DIR}/libtdefakes_nonpic.a ${SENSORS_LIBRARIES} ^^^^^^^^^^^^^^^^^^^^ DESTINATION ${BIN_INSTALL_DIR} )

On 01/20/2014 01:21 PM, Slávek Banko wrote:

On Monday 20 of January 2014 20:13:02 David C. Rankin wrote:

...

On 01/20/2014 11:25 AM, Slávek Banko wrote:

...

How did you come to the conclusion that building ksysguardd depends on WITH_SENSORS? I do not see any such condition in CMake files.

(1) Because ksysguard is the wonderful monitoring package; (2) that uses system hardware sensors; (3) I've never run into this missing file before; and (4) this was the first time I have ever built WITH_SENSORS.

Elementary my dear Mr. Watson...

Oh,

Also, in the CMakeLists.txt file where I had to fix this screwy filename, I found this....

##### ksysguardd (executable) ###################

tde_add_executable( ksysguardd AUTOMOC SOURCES Command.c conf.c ksysguardd.c PWUIDCache.c LINK ccont-static ksysguardd-static ${TDE_LIB_DIR}/libtdefakes_nonpic.a ${SENSORS_LIBRARIES} ^^^^^^^^^^^^^^^^^^^^ DESTINATION ${BIN_INSTALL_DIR} )

If WITH_SENSORS is OFF, variable ${SENSORS_LIBRARIES} is empty and ksysguardd is built without problems, just without lm_sensors support. It's not option without which it would be impossible to build ksysguardd.

Slavek

I'm trying to nail this problem down at the moment and I'm not sure why the '.a' files are not in my install. The files were generated and made part of the package when tdelibs was built. From the tdelibs build log:

13:55 phoinix:/dat_e/tde/log> grep libtdefake tde-tdelibs.log Linking C shared library libtdefakes.so /usr/bin/cc -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wl,--no-undefined -shared -Wl,-soname,libtdefakes.so.14 -o libtdefakes.so.14.0.0 CMakeFiles/tdefakes-shared.dir/fakes.c.o CMakeFiles/tdefakes-shared.dir/vsnprintf.c.o -L/opt/tqt3/lib cd /build/tde-tdelibs/src/build/tdecore && /usr/bin/cmake -E cmake_symlink_library libtdefakes.so.14.0.0 libtdefakes.so.14 libtdefakes.so Linking C static library libtdefakes_nonpic.a /usr/bin/ar cr libtdefakes_nonpic.a CMakeFiles/tdefakes_nonpic-static.dir/fakes.c.o CMakeFiles/tdefakes_nonpic-static.dir/vsnprintf.c.o /usr/bin/ranlib libtdefakes_nonpic.a Linking C static library libtdefakes_pic.a /usr/bin/ar cr libtdefakes_pic.a CMakeFiles/tdefakes_pic-static.dir/fakes.c.o CMakeFiles/tdefakes_pic-static.dir/vsnprintf.c.o /usr/bin/ranlib libtdefakes_pic.a /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/tqt3/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/tdestartupconfig.dir/tdestartupconfig.cpp.o -o tdestartupconfig -L/opt/tqt3/lib -rdynamic ../tdecore/libtdefakes.so.14.0.0 -ltqt -ltqt-mt -Wl,-rpath,/opt/tqt3/lib:/build/tde-tdelibs/src/build/tdecore: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/cupsdoprint.dir/cupsdoprint.c.o -o cupsdoprint -L/opt/tqt3/lib -rdynamic ../../tdecore/libtdefakes.so.14.0.0 -lcups -Wl,-rpath,/opt/tqt3/lib:/build/tde-tdelibs/src/build/tdecore: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/make_driver_db_cups.dir/make_driver_db_cups.c.o -o make_driver_db_cups -L/opt/tqt3/lib -rdynamic ../libdriverparse.a ../../tdecore/libtdefakes.so.14.0.0 -lz -ldl -Wl,-rpath,/opt/tqt3/lib:/build/tde-tdelibs/src/build/tdecore: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/make_driver_db_lpr.dir/make_driver_db_lpr.c.o -o make_driver_db_lpr -L/opt/tqt3/lib -rdynamic ../libdriverparse.a ../../tdecore/libtdefakes.so.14.0.0 -ldl -Wl,-rpath,/opt/tqt3/lib:/build/tde-tdelibs/src/build/tdecore: -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes_nonpic.a -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes_pic.a -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.so.14.0.0 -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.so.14 -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.so -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.la

So the libtdefakes_nonpic.a and libtdefakes_pic.a were 'installed' by 'make install', but were later somehow stripped in packaging. Now it is NOT something I did intentionally because my package() function for tdelibs is:

package() { msg "Packaging - $pkgname-$pkgver" cd ${srcdir}/build

make -j1 DESTDIR="$pkgdir" install }

That's it! So if the '.a' files are gone, then Arch's packaging software automatically strips them internally. That is what I'm trying to track down.

What is the contents of your libtdefakes_nonpic.a and libtdefakes_pic.a files?

On 01/20/2014 02:26 PM, Slávek Banko wrote:

The files '*.a' are binary. I did not inquire, what is the purpose of this library.

Well, I can only surmise that the pic and nopic correspond to the kernel parameters apic and noapic for graphics handling. I can't explain the absence of the files, they were there when I was building a year ago, so this is something new in Arch. e.g.:

tar -tJf tde-tdelibs-3.5.14_dev-1-x86_64.pkg.tar.xz | grep tdefakes tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' opt/trinity/lib/libtdefakes.so opt/trinity/lib/libtdefakes_pic.a opt/trinity/lib/libtdefakes_nonpic.a opt/trinity/lib/libtdefakes.la opt/trinity/lib/libtdefakes.so.4 opt/trinity/lib/libtdefakes.so.4.2.0

On 01/20/2014 02:18 PM, David C. Rankin wrote:

That's it! So if the '.a' files are gone, then Arch's packaging software automatically strips them internally. That is what I'm trying to track down.

It is a new option in the arch packaging app that strips static libraries by default:

On 29/09/13 17:36, Allan McRae wrote:

All this recent talk about static libs reminded me that we added options=(!staticlibs) to makepkg-4.1 to automatically remove them, with the idea of enabling it by default.

<snip> Once devtools is updated, I will generate a rebuild list. If your package really needs static libs, you will need to add options=(staticlibs) to the PKGBUILD. The packages I know that need it are glibc, gcc, binutils, haskell, probably lua (but we hack that for shared libraries...). So if you are not dealing with a compiler, you probably do not need them...

(he is no light-weight in distributions/software packaging)

HOWEVER, this exploit does raise a legitimate issue - all current software (excluding compilers) has done away with all reliance on static libraries. That may be something we want to look at for TDE as we go forward.

The immediate question is what packages currently rely on static libraries in TDE? So far the first FTBFS related to static libs has been tdebase/ksysguard relying on static libs from tdelibs.

Should we open a bug to track failures related to reliance on static libs.

On 01/20/2014 03:43 PM, Juergen Beisert wrote:

A *.a archive does not mean it is always a static library. The autotools for example use them for internal libraries only. 'internal' means they get not installed when "make install" runs, they are linked internally against the produced binary, whatever it is. If this internal *.a library is intended to be linked against an application its content is mostly compiled as NOPIC. If it is intended to be linked against a shared library its content must be compiled as PIC. Thought this info could help you to sort out why the TDE buildsystem builds more than variant of this library.

jbe

jbe,

Thank you. It would have taken me hours to dig that knowledge up. And see my presumption about it being graphics related was totally wrong. I'm no autotools/cmake guru -- I end up fighting with them both more than using them. Glad to know what an autotools archive is and at least understand what PIC and NOPIC means in this context.