Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #752 > unrolled thread

Qt: Can't build statically linked app

Back to article view | Back to comp.os.linux.development.apps

Contents

  Qt: Can't build statically linked app j.livermont.ericsson@gmail.com - 2014-08-28 07:46 -0700
    Re: Qt: Can't build statically linked app Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-08-28 16:11 +0100

#752 — Qt: Can't build statically linked app

I'm trying to build an Qt-based application that's recently been uplifted from Qt4.x to Qt5.  I am able to get the app to compile fine, but I would like to it to be statically linked for portability across our test and CI environments.

A colleague of mine suggested that all I needed to do was add 'CONFIG += static' to my .pro file and rebuild.  I did that, but I still end up with a dynamically linked binary.

Does anyone have any tips on what I would need to do to get this binary statically linked?

[jlivermo@odin phantomjs2]$ file bin/phantomjs 
bin/phantomjs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[jlivermo@odin phantomjs2]$ ldd bin/phantomjs 
	linux-vdso.so.1 =>  (0x00007fff4c98c000)
	libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x0000003970c00000)
	libicudata.so.42 => /usr/lib64/libicudata.so.42 (0x0000003974800000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003963400000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003962000000)
	libicui18n.so.42 => /usr/lib64/libicui18n.so.42 (0x000000396c000000)
	libicuuc.so.42 => /usr/lib64/libicuuc.so.42 (0x000000396d800000)
	libdl.so.2 => /lib64/libdl.so.2 (0x000000395ec00000)
	librt.so.1 => /lib64/librt.so.1 (0x000000395f400000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x000000395e800000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000396b000000)
	libm.so.6 => /lib64/libm.so.6 (0x000000395e000000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003968c00000)
	libc.so.6 => /lib64/libc.so.6 (0x000000395e400000)
	/lib64/ld-linux-x86-64.so.2 (0x000000395dc00000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003962c00000)
[jlivermo@odin phantomjs2]$ cat phantomjs.pro 
TEMPLATE = subdirs
CONFIG += ordered
CONFIG += static
SUBDIRS += src/phantomjs.pro

[toc] | [next] | [standalone]

#753

j.livermont.ericsson@gmail.com writes:
> I'm trying to build an Qt-based application that's recently been
> uplifted from Qt4.x to Qt5.  I am able to get the app to compile fine,
> but I would like to it to be statically linked for portability across
> our test and CI environments.

Are you trying to solve an actual problem by doing this or is the just
the usual "that's fishy and I'd rather not do that" reflex?

> A colleague of mine suggested that all I needed to do was add 'CONFIG
> += static' to my .pro file and rebuild.  I did that, but I still end
> up with a dynamically linked binary.

gcc will create a statically linked binary when the -static command-line
option is being used:


[rw@sable]/tmp#ed a.c
a.c: No such file or directory
a
#include <stdio.h>

int main(void)
{
        puts("I'm old-fashioned!");
        return 0;
}
.
wq
79
[rw@sable]/tmp#gcc -static a.c
[rw@sable]/tmp#./a.out 
I'm old-fashioned!
[rw@sable]/tmp#ldd a.out 
        not a dynamic executable

Whatever your integrated developer playpen may be, I figure it should
have a way to pass additional options to the linker.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.development.apps

csiph-web