GNOME Bugzilla – Bug 640202
For GLIB v. 2.23.6 and above: impossibility to build multi-architecture libraries due to gvariant.c - Jan. 21, 2011
Last modified: 2016-07-08 07:14:23 UTC
Platform: Mac Intel Core 2 Duo, 1 GB memory OS: Mac OS X Snow Leopard (v. 10.6.6) IDE & related development tools (e.g., GNU compilers): Xcode 3.2.5 #=============================================== Desired or expected feature: building in one pass GLIB libraries according to GNU compiler suite documentation in such that way for example, CC="gcc -arch i386 -arch x86_64", etc. #=== The matter: until the version n° 2.23.5, eveything seems to go alright (apart some tests failing or blocking). My report, with enclosed ZIP files (in which you will find ASCII log files), is as follows: 1. Preliminary remark: for all versiosn, until 2.27.91, ./configure issues this kind of message : ld: unknown option -export-dynamic collect2: ld returned 1 exit status lipo:'can't open input file:/var/floders/YF/...//ccrf4RR6H.out (no such file or directory) 2. OUR PURPOSE: gvariant.c issuing bugs Answer to the question: " success in building multi-architecture in one pass (Y/N) (with possible comment) ?" v. 2.19.10 => Y (but a few tests or tests blocking) v. 2.20.5 => Y ( " ) | v. 2.21.6 => Y ( --- please kindly see the log files) | v. 2.22.5 => Y ( " ) <-| v. 2.23.5 => Y ( " ) v. 2.23.6 => N (gvariant.c:3234:error:size of array 'Compile_Time_Assertion' is negative lipo:can't found the architecture of:/var/folders/Yf/...//ccSBNvRA.out) v. 2.24.2 => N (gvariant.c:3240 - similar error message) v. 2.25.17 => N (gvariant.c:3735 - " ) v. 2.26.0 => N (gvariant.c:3735 - " ) v. 2.27.4 => N (gvariant.c:3879 - " ) v. 2.27.90 => N (gvariant.c:3882 - " ) v. 2.27.91 => N (gvariant.c:3882 - " ) #====== EXPECTED: same shell script as for v. 2.23.5 to build multi-architecture libraries in one pass. gvariant.c working is espected in order not to use lipo 'manually' to build fat files.. REMARK: replacing gvariant.c for all versions from v. 2.23.6 by gvariant.c of v. 2.23.5 issues other kind(s) of error.
Created attachment 178955 [details] log files in ZIP format
Created attachment 178956 [details] log files in ZIP format
Created attachment 178957 [details] log files in ZIP format
Created attachment 178958 [details] log files in ZIP format
Created attachment 178960 [details] 2011-01-20-SUCCESS-SnowLeopard-v_2_19_10
Created attachment 178961 [details] 2011-01-20-SUCCESS-SnowLeopard-v_2_20_5
Created attachment 178962 [details] 2011-01-20-SUCCESS-SnowLeopard-v_2_21_6
Created attachment 178963 [details] 2011-01-20-SUCCESS-SnowLeopard-v_2_22_5
Created attachment 178964 [details] 2011-01-20-SUCCESS-SnowLeopard-v_2_23_5
Created attachment 178965 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_23_6
Created attachment 178966 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_24_2
Created attachment 178967 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_25_17
Created attachment 178968 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_26_0
Created attachment 178969 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_27_4
Created attachment 178970 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_27_90
Created attachment 178971 [details] 2011-01-20-FAILURE-SnowLeopard-v_2_27_91
Can you please provide a small description of what the actual problem is, inline, so that I don't have to look through 16 zip files? A gcc error message would be fine....
*** Bug 640201 has been marked as a duplicate of this bug. ***
I can reproduce it. Here's what I see in context during ./configure (note, I have a setup that does not do multiarch, so lipo is not used): checking for dlopen... yes checking for dlsym... yes ld: unknown option: -export-dynamic collect2: ld returned 1 exit status checking for RTLD_GLOBAL brokenness... no Running manually in my shell the relevant configure.ac scripting: $ echo "void glib_plugin_test(void) { }" > plugin.c $ ./libtool --mode=compile gcc -shared -export-dynamic -o plugin.o plugin.c libtool: compile: gcc -export-dynamic plugin.c -fno-common -DPIC -o .libs/plugin.o ld: unknown option: -export-dynamic collect2: ld returned 1 exit status So the generated libtool script is propagating the -export-dynamic flag to the compiler, which is propagating it to the linker, which doesn't recognize it. My gcc manpage says that this flag is specific to the ELF linker, and OS X isn't ELFish.
Created attachment 179006 [details] [review] Patch to fix non-portable libtool usage in configure script This should fix it.
Created attachment 179012 [details] [review] Same patch, just smaller This patch is smaller, doesn't require knowing libtool's module extension (uses -shrext to specify it) but should still be portable.
Using patch in Comment #20, :checking for dlopen... yes :checking for dlsym... yes :checking for the suffix of module shared libraries... .so :checking for RTLD_GLOBAL brokenness... no The configure.ac comment says it's for OSF1/5.0, which my OS X 10.6 machine definitely isn't, so this fixes the coding portability problem and gives correct result. The patch in Comment #21 gives same result as Comment #20.
Thanks for investigation! Let's hope that a glib maintainer comes around and has a look at the patch :-)
I am tempted to say that we should just drop the test for OSF1/5.0 problems... But if this change fixes your problem and doesn't break Linux, I have no objections.
Review of attachment 179012 [details] [review]: looks good to me as well.
Pushed to master. Should I backport it to 2.30?
Now that we're on 2.32.x stable which does include this fix, Comment #26 is moot and this whole bug can be closed [resolved]-[fixed]?
Closing per comment 27.
This patch also resolved Bug 583010