Opened 9 years ago
Closed 8 years ago
#181 closed defect (fixed)
Pkg-config no longer builds Mozilla
Reported by: | Dave Yeo | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | |
Component: | spec files | Version: | |
Severity: | low | Keywords: | glibc |
Cc: | Dave Yeo |
Description
After updating pkg-config to 029.1-2oc00, building SeaMonkey fails while running the Firefox configure script here,
configure:19422: checking for pkg-config configure: error: Library requirements (pango >= 1.22.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
Downgrading pkg-config to 25-4(oc00) allows the build to proceed.
Attachments (2)
Change History (15)
comment:1 by , 9 years ago
Priority: | major → Feedback Pending |
---|
comment:2 by , 9 years ago
ok I figured this out. It's not a pkg-config issue, but a glib issue.
If you do "SET CODEPAGE=CP850" it works again.
The reason is, that glib brings back some charset like en_US and of course iconv() can't convert en_US to UTF-8
comment:3 by , 9 years ago
or to be even more accurate, our glib rpm doesn't provide the charset.alias table.
With this it would work w/o the need of the above set statement
by , 9 years ago
Attachment: | charset.alias added |
---|
comment:5 by , 9 years ago
Cc: | added |
---|
Adding charset.alias and setting CODEPAGE=CP850 does not fix the issue, from config.log
configure:19422: checking for pkg-config configure: error: Library requirements (pango >= 1.22.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
the failing test (about line# 19471 of mozilla/configure) seems to be
if $PKG_CONFIG --exists "pango >= $PANGO_VERSION" ; then echo "$ac_t""yes" 1>&6 succeeded=yes
BTW, exactly same error when building Firefox as expected.
comment:7 by , 9 years ago
It was a download error, shift-clicking downloaded the page source. I had to click charset.alias to display it with line numbers then click download in other formats--> original.
Now it is working. I guess this can be closed once the charset.alias file is packaged somehow, perhaps a new glib2 build, and added to the repository.
comment:8 by , 9 years ago
Component: | rpm → spec files |
---|---|
Keywords: | glibc added |
Priority: | Feedback Pending → critical |
We either change the way glib works, or deliver the charset.alias in the rpm.
I leave the ticket open until this is done.
And I'm glad it works now for you as well.
comment:9 by , 9 years ago
echo "$l ASCII" 360 361 echo "$l.ASCII ASCII" 361 362 done 362 363 for l in da_DK de_AT de_CH de_DE en_AU en_CA en_GB en_US es_ES \ 363 364 fi_FI fr_BE fr_CA fr_CH fr_FR is_IS it_CH it_IT la_LN \ 364 365 lt_LN nl_BE nl_NL no_NO pt_PT sv_SE; do 366 echo "$l ISO-8859-1"
Should that not be ISO-8859-15? Basically the same as ISO-8859-1 but has the EURO symbol IIRC.
BTW, I notice that the Cc does not result in my receiving messages.
comment:10 by , 9 years ago
probably you are right, we should use the ISO-8859-15.
Shouldn't cc have the complete e-mail address? Or can't I just not see the complete one?
comment:11 by , 9 years ago
The email address is set in my preferences, or rather was set in my preferences. Hopefully fixed.
comment:12 by , 8 years ago
The ISO-8859-15 cannot be used, it does not provide a conversion to UTF-8, or at least our code does not provide it.
I have also added _EURO locales to table in
http://trac.netlabs.org/ports/changeset/1605
This is part of glib2 2.33.12 upcoming release.
comment:13 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
glib2 is now in exp repo, so closing this case
isn't there some more info in the config.log?