[Bug other/112671] New: libiconv support lacks separate --with-libiconv-{include,lib}

[Bug other/112671] New: libiconv support lacks separate --with-libiconv-{include,lib}

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671

            Bug ID: 112671
           Summary: libiconv support lacks separate
                    --with-libiconv-{include,lib}
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

When trying to build trunk on Solaris with GNU libiconv 1.17, I noticed that
the libiconv configure support is limited compared to e.g. gmp etc.  On
multilibbed targets like Solaris, you usually install both 32 and 64-bit
versions of a library into <libiconv-prefix>/include (common between 32 and
64-bit) and <libiconv-prefix>/lib (32-bit lib) resp.
<libiconv-prefix>/lib/{amd64,sparcv9}.

The current (simple-minded) support via --with-libiconv-prefix cannot handle
this,
requiring to use two different installations into different prefixes.  It's
also inconsistent with the rest of gcc which does support configurations like
this.

[Bug other/112671] libiconv support lacks separate --with-libiconv-{include,lib}

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671

--- Comment #1 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
yes, this also came up from the binutils side.  see
https://inbox.sourceware.org/binutils/874jhg2x6p.fsf@adacore.com/

I will restore the modifications in the shared tree with the few other patches
I mentioned on the GCC ML recently soon (I've ran a little low on testing
bandwidth this week..)

apologies for the inconvenience

[Bug other/112671] libiconv support lacks separate --with-libiconv-{include,lib}

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
[...]
> I will restore the modifications in the shared tree with the few other patches
> I mentioned on the GCC ML recently soon (I've ran a little low on testing
> bandwidth this week..)
>
> apologies for the inconvenience

No worries, this is the first time ever I tried this on Solaris and can
easily live with 32-bit-only testing for now.

Thanks for taking care of this.

[Bug other/112671] libiconv support lacks separate --with-libiconv-{include,lib}

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671

--- Comment #3 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
hm, actually, I think I confused reports - sorry.

do you know if this worked a short while ago?  and if so, how did such a
configuration look?

[Bug other/112671] libiconv support lacks separate --with-libiconv-{include,lib}

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
> hm, actually, I think I confused reports - sorry.
>
> do you know if this worked a short while ago?  and if so, how did such a
> configuration look?

I have no idea: at least AFAICS back to the gcc-11 branch (didn't look
further) there was only --with-libiconv-prefix.

Still it's inconsistent with how many (all?) other support libs are
handled.