https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
Alexios Zavras (zvr) changed:
What|Removed |Added
CC||zvr+gcc at zvr dot gr
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #13 from Liviu Ionescu ---
I'm not sure what the best solution might be, but it looks like the configure
script can detect the case when a distinct libiconv is encountered.
In this case the only thing that is needed is an explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #12 from Liviu Ionescu ---
--without-libiconv-prefix did not prevent configure to pick the new libiconv,
the behaviour was exactlly the same.
The only way I could make it pass was to completely remove the new libiconv.
Although I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #11 from Liviu Ionescu ---
> --without-libiconv-prefix looks promising
I'll try it tomorrow and let you know.
Thank you,
Liviu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #10 from Jonathan Wakely ---
(In reply to Liviu Ionescu from comment #8)
> Is there any way to prevent GCC from picking the freshly compiled libiconv
> and use the system one?
Try the options I suggested. --without-libiconv-prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #9 from Jonathan Wakely ---
Ah, something did change: we now use automake-1.15.1 and autoconf-2.69 and
that's where all the iconv handling comes from (via the AM_ICONV macro).
Presumably that changed in upstream automake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #8 from Liviu Ionescu ---
> I would guess either /usr/local/include or ${INSTALL_FOLDER_PATH}/include
Yes, but I have exactly the same configuration when I build GCC 8.x and 7.x,
and GCC does not get confused, the problem occurred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #7 from Jonathan Wakely ---
(In reply to Liviu Ionescu from comment #0)
> GCC 7.x and 8.x are fine, with the same build procedure the libstdc++ shared
> library has no undefined references to libiconv.
Have you checked that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #6 from Liviu Ionescu ---
> I think you have libiconv installed locally, which defines the libiconv_xxx
> functions.
That's correct, I have the latest libiconv compiled from sources and GCC (like
many other programs) correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #5 from Liviu Ionescu ---
> I think you have libiconv installed locally, which defines the libiconv_xxx
> functions.
That's correct, I have the latest libiconv compiled from sources and GCC (like
many other programs) correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #3 from Liviu Ionescu ---
The actual configure line is:
bash ${DEBUG}
"${SOURCES_FOLDER_PATH}/${native_gcc_folder_name}/configure" \
--prefix="${INSTALL_FOLDER_PATH}" \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #2 from Jonathan Wakely ---
I think you have libiconv installed locally, which defines the libiconv_xxx
functions. That is being found by GCC instead of the symbols in glibc, as
normally happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
14 matches
Mail list logo
