9:58 a.m.
I ran into an issue on x86_64 and fc6/devel trying to build qt4,
http://buildsys.fedoraproject.org/logs/fedora-development-extras/12668-qt...
In short, I received the error:
/usr/bin/ld: .obj/release-shared/qthread_unix.o: relocation R_X86_64_PC32
against `pthread_cond_timedwait@(a)GLIBC_2.3.2' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
Funny thing is (afaict)... qthread_unix.o *was* built with -fPIC.
-- Rex
12:28 p.m.
Rex Dieter wrote:
I ran into an issue on x86_64 and fc6/devel trying to build qt4,
http://buildsys.fedoraproject.org/logs/fedora-development-extras/12668-qt...
In short, I received the error:
/usr/bin/ld: .obj/release-shared/qthread_unix.o: relocation R_X86_64_PC32
against `pthread_cond_timedwait@(a)GLIBC_2.3.2' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
Funny thing is (afaict)... qthread_unix.o *was* built with -fPIC.
Are you sure? Maybe it contains inline asm which is not PIC? I've seen
similar messages before and there always is a real good reason for them
Regards,
Hans
9:49 a.m.
Hans de Goede wrote:
Rex Dieter wrote:
> I ran into an issue on x86_64 and fc6/devel trying to build qt4,
>
http://buildsys.fedoraproject.org/logs/fedora-development-extras/12668-qt...
> In short, I received the error:
> /usr/bin/ld: .obj/release-shared/qthread_unix.o: relocation R_X86_64_PC32
> against `pthread_cond_timedwait@(a)GLIBC_2.3.2' can not be used when making a
> shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
>
> Funny thing is (afaict)... qthread_unix.o *was* built with -fPIC.
>
Are you sure? Maybe it contains inline asm which is not PIC? I've seen
similar messages before and there always is a real good reason for them
I'll go (re)check for asm, but I can say this same pkg built fine on Jul
03, so something changed in the meantime... (:
-- Rex
9:35 a.m.
On Mon, 2006-07-17 at 09:49 -0500, Rex Dieter wrote:
Hans de Goede wrote:
>
> Rex Dieter wrote:
>> I ran into an issue on x86_64 and fc6/devel trying to build qt4,
>>
http://buildsys.fedoraproject.org/logs/fedora-development-extras/12668-qt...
>> In short, I received the error:
>> /usr/bin/ld: .obj/release-shared/qthread_unix.o: relocation R_X86_64_PC32
>> against `pthread_cond_timedwait@(a)GLIBC_2.3.2' can not be used when making a
>> shared object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Bad value
>>
>> Funny thing is (afaict)... qthread_unix.o *was* built with -fPIC.
>>
>
> Are you sure? Maybe it contains inline asm which is not PIC? I've seen
> similar messages before and there always is a real good reason for them
I'll go (re)check for asm, but I can say this same pkg built fine on Jul
03, so something changed in the meantime... (:
Maybe post the relevant code for the use in qthread_unix.c[pp|xx] of the
pthread function which caused the above link error. I had an odd
R_X86_64_PC32 error in OOo which I was able to workaround by making the
afflicted global arrays into local function static arrays.
(openoffice.org-2.0.3.gccXXXXX.svtools.R_X86_64_PC32.patch in the OOo
src.rpm)
C.
9:45 a.m.
On Mon, Jul 17, 2006 at 03:35:08PM +0100, Caolan McNamara wrote:
Maybe post the relevant code for the use in qthread_unix.c[pp|xx] of
the
pthread function which caused the above link error. I had an odd
R_X86_64_PC32 error in OOo which I was able to workaround by making the
afflicted global arrays into local function static arrays.
(openoffice.org-2.0.3.gccXXXXX.svtools.R_X86_64_PC32.patch in the OOo
src.rpm)
Here you talk about http://gcc.gnu.org/PR28370, right?
That's already fixed in gcc-4.1.1-8.
Jakub
9:47 a.m.
On Mon, 2006-07-17 at 10:45 -0400, Jakub Jelinek wrote:
On Mon, Jul 17, 2006 at 03:35:08PM +0100, Caolan McNamara wrote:
> Maybe post the relevant code for the use in qthread_unix.c[pp|xx] of the
> pthread function which caused the above link error. I had an odd
> R_X86_64_PC32 error in OOo which I was able to workaround by making the
> afflicted global arrays into local function static arrays.
>
> (openoffice.org-2.0.3.gccXXXXX.svtools.R_X86_64_PC32.patch in the OOo
> src.rpm)
Here you talk about http://gcc.gnu.org/PR28370, right?
That's already fixed in gcc-4.1.1-8.
No, something else which I never got around to tracking down. Might also
be fixed, but it was/is an x86_64 only problem.
C.
11:18 a.m.
Rex Dieter wrote:
Hans de Goede wrote:
>
> Rex Dieter wrote:
>> I ran into an issue on x86_64 and fc6/devel trying to build qt4,
>>
http://buildsys.fedoraproject.org/logs/fedora-development-extras/12668-qt...
>> In short, I received the error:
>> /usr/bin/ld: .obj/release-shared/qthread_unix.o: relocation
>> R_X86_64_PC32 against `pthread_cond_timedwait@(a)GLIBC_2.3.2' can not be
>> used when making a shared object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Bad value
>>
>> Funny thing is (afaict)... qthread_unix.o *was* built with -fPIC.
>>
>
> Are you sure? Maybe it contains inline asm which is not PIC? I've seen
> similar messages before and there always is a real good reason for them
I'll go (re)check for asm, but I can say this same pkg built fine on Jul
03, so something changed in the meantime... (:
I've confirmed there is no asm, and the file in question *was* built
with -fPIC:
g++ -c -m64 -pipe -I/usr/include/mysql -fno-exceptions -O2 -g -pipe -Wall \
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m64 \
-mtune=generic -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W \
-D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII \
-DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++-64 -I. -I../../include \
-I../../include/QtCore -Iglobal -I.moc/release-shared -I. \
-o .obj/release-shared/qthread_unix.o thread/qthread_unix.cpp
-- Rex
6:18 p.m.
On Wed, 2006-07-19 at 11:18 -0500, Rex Dieter wrote:
Rex Dieter wrote:
I've confirmed there is no asm, and the file in question *was* built
with -fPIC:
g++ -c -m64 -pipe -I/usr/include/mysql -fno-exceptions -O2 -g -pipe -Wall \
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m64 \
-mtune=generic -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W \
-D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII \
-DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++-64 -I. -I../../include \
-I../../include/QtCore -Iglobal -I.moc/release-shared -I. \
-o .obj/release-shared/qthread_unix.o thread/qthread_unix.cpp
-- Rex
Try disabling visibility support, it doesn't currently work in the devel
gcc the way qt probably expects it to, i.e. add
"-no-reduce-exports"
to your qt4.spec's configure line
C.
p.s. I suggest adding -fno-strict-aliasing to your compile flags, there
are a lot of warnings about aliasing issues in that build which are
likely to be real problems.
7:06 a.m.
Caolan McNamara wrote:
On Wed, 2006-07-19 at 11:18 -0500, Rex Dieter wrote:
> Rex Dieter wrote:
>
> I've confirmed there is no asm, and the file in question *was* built
> with -fPIC:
>
> g++ -c -m64 -pipe -I/usr/include/mysql -fno-exceptions -O2 -g -pipe -Wall
> \ -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
> -m64 \ -mtune=generic -fvisibility=hidden -fvisibility-inlines-hidden
> -Wall -W \
> -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
> \ -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE \
> -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++-64 -I. -I../../include \
> -I../../include/QtCore -Iglobal -I.moc/release-shared -I. \
> -o .obj/release-shared/qthread_unix.o thread/qthread_unix.cpp
Try disabling visibility support, it doesn't currently work in
the devel
gcc the way qt probably expects it to, i.e. add
"-no-reduce-exports"
to your qt4.spec's configure line
Thanks. Is there a bugzilla on this and/or when can we expect -fvisibility
to be fixed?
p.s. I suggest adding -fno-strict-aliasing to your compile flags,
there
are a lot of warnings about aliasing issues in that build which are
likely to be real problems.
In "that build" you mean that build of gcc? So this only affects the
fc6/devel branch (for now)?
-- Rex
7:43 p.m.
On Thu, 2006-07-20 at 07:06 -0500, Rex Dieter wrote:
Caolan McNamara wrote:
> On Wed, 2006-07-19 at 11:18 -0500, Rex Dieter wrote:
>> Rex Dieter wrote:
>>
>
> Try disabling visibility support, it doesn't currently work in the devel
> gcc the way qt probably expects it to, i.e. add
> "-no-reduce-exports"
> to your qt4.spec's configure line
Thanks. Is there a bugzilla on this and/or when can we expect -fvisibility
to be fixed?
There's a big chat about it at
http://gcc.gnu.org/ml/gcc/2006-07/threads.html#00204
I don't know if visibility should actually be called "broken" so as to
be fixed, but it has changed sufficiently that existing markup doesn't
really cut it anymore :-(
> p.s. I suggest adding -fno-strict-aliasing to your compile flags, there
> are a lot of warnings about aliasing issues in that build which are
> likely to be real problems.
In "that build" you mean that build of gcc? So this only affects the
fc6/devel branch (for now)?
No, I just meant that from that build.log I can see plenty of warnings
about "dereferencing type-punned pointer will break strict-aliasing
rules"
http://buildsys.fedoraproject.org/logs/fedora-development-extras/12668-qt...
That's not a new thing, nor is it a problem of gcc, but generally is a
real warning that the code is somewhat busted, but -fno-strict-aliasing
will avoid the problems that this optimization would otherwise trigger
in the dodgy code.
C.
5:40 a.m.
On Thu, 2006-07-20 at 07:06 -0500, Rex Dieter wrote:
Caolan McNamara wrote:
> On Wed, 2006-07-19 at 11:18 -0500, Rex Dieter wrote:
>> Rex Dieter wrote:
>>
>> I've confirmed there is no asm, and the file in question *was* built
>> with -fPIC:
>>
>> g++ -c -m64 -pipe -I/usr/include/mysql -fno-exceptions -O2 -g -pipe -Wall
>> \ -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -m64 \ -mtune=generic -fvisibility=hidden -fvisibility-inlines-hidden
>> -Wall -W \
>> -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
>> \ -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE \
>> -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++-64 -I. -I../../include \
>> -I../../include/QtCore -Iglobal -I.moc/release-shared -I. \
>> -o .obj/release-shared/qthread_unix.o thread/qthread_unix.cpp
> Try disabling visibility support, it doesn't currently work in the devel
> gcc the way qt probably expects it to, i.e. add
> "-no-reduce-exports"
> to your qt4.spec's configure line
Thanks. Is there a bugzilla on this and/or when can we expect -fvisibility
to be fixed?
well... there is no reason to add -fvisibility with current gcc's... the
default behavior is the optimized right one already
12:50 p.m.
On Mon, 2006-07-24 at 12:40 +0200, Arjan van de Ven wrote:
On Thu, 2006-07-20 at 07:06 -0500, Rex Dieter wrote:
>
> Thanks. Is there a bugzilla on this and/or when can we expect -fvisibility
> to be fixed?
well... there is no reason to add -fvisibility with current gcc's... the
default behavior is the optimized right one already
I'm not at all sure about that, if you mean 4.1.1-9 as current gcc. The
unpushed gcc's >= 4.1.1-10 seem to do what OOo and qt apps want in
relation to visibility. So the -fvisibility feature looks set to change
in the next pushed gcc.
There's still seems plenty of reason to use -fvisibility and visibility
markup to reduce the number of exported C++ symbols, despite the welcome
new hash and local linkage of anonymous namespace symbols.
C.
6491
days inactive
6498
days old
11 comments
5 participants
participants (5)
-
Arjan van de Ven -
Caolán McNamara -
Hans de Goede -
Jakub Jelinek -
Rex Dieter