[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gawkextlib installation issues
From: |
Eli Zaretskii |
Subject: |
Re: gawkextlib installation issues |
Date: |
Thu, 19 May 2022 18:59:49 +0300 |
> Date: Thu, 19 May 2022 10:52:45 -0400
> From: "Andrew J. Schorr" <aschorr@telemetry-investments.com>
> Cc: Manuel Collado <mcollado2011@gmail.com>, arnold@skeeve.com,
> bug-gawk@gnu.org
>
> > This means that --with-gmp, --with-mpfr, and --with-gawkextlib cannot
> > be safely given with a value of $prefix, but should instead be
> > given with the value of $prefix/lib.
> >
> > One possible fix would be to explicitly check for lib64, but even that
> > could be problematic, since one could have, say, 32-bit and 64-bit
> > libraries in 2 separate directories, and the above test could pick up
> > the wrong one.
>
> Interesting. I'm not certain that we can build a bullet-proof script
> that will protect against every idiosyncratic setup. What we can do
> is improve documentation and add options to make sure people are able
> to get it to work if they know what they are doing.
>
> For Unix users, we try to support 2 general cases:
>
> 1. Packages are installed in the standard locations under /usr,
> and no configure arguments are required, because the binaries and
> libraries and include files are in the standard directories that will
> be found automatically.
>
> 2. A particular package was installed in a nonstandard directory tree using
> --prefix, in which case the various "--with-*" options just need to point
> to that prefix.
>
> If people do unexpected things, like installing side-by-side 32-bit
> and 64-bit packages under the same prefix, it seems impossible to do
> the right thing without further direction from the installer. But it's
> possible that we may need more configure script arguments to enable that.
>
> One could generally have more granular "--with-<package>-include-dir"
> and "--with-<package>-lib-dir" options. Is that what's needed?
> Or should we leave it as is for now?
If you think checking for specific names instead of a catch-all "lib*"
is an overkill, I think documenting this would be enough.
(I used the --with-gawkextlib= option to mimic what Manuel did, in
case that somehow mattered; I don't really need to use that option,
since on my system packages are "installed in the standard locations".)
- Re: Avoid gawkextlib as a separate shared library, (continued)
- Re: Avoid gawkextlib as a separate shared library, Manuel Collado, 2022/05/18
- Re: Avoid gawkextlib as a separate shared library, Eli Zaretskii, 2022/05/18
- Re: Avoid gawkextlib as a separate shared library, Manuel Collado, 2022/05/18
- Re: Avoid gawkextlib as a separate shared library, Eli Zaretskii, 2022/05/19
- Found a libtool issue (vas: Avoid gawkextlib as a separate shared library), Manuel Collado, 2022/05/19
- Re: Found a libtool issue (vas: Avoid gawkextlib as a separate shared library), Eli Zaretskii, 2022/05/19
- Re: Found a libtool issue, Manuel Collado, 2022/05/19
- Re: Found a libtool issue, Eli Zaretskii, 2022/05/19
- Re: Avoid gawkextlib as a separate shared library, Eli Zaretskii, 2022/05/19
- Re: gawkextlib installation issues, Andrew J. Schorr, 2022/05/19
- Re: gawkextlib installation issues,
Eli Zaretskii <=
- Re: gawkextlib installation issues, Manuel Collado, 2022/05/19
- Re: MinGw port of gawkextlib (was: Extension packaging), Eli Zaretskii, 2022/05/11
- Re: MinGw port of gawkextlib, Manuel Collado, 2022/05/11
- Re: MinGw port of gawkextlib, Eli Zaretskii, 2022/05/11
- Message not available
- Re: Extension packaging, Manuel Collado, 2022/05/11
- Re: Extension packaging, arnold, 2022/05/11
- Re: Extension packaging, arnold, 2022/05/10
- Re: [gawk-devel] MPFR thoughts, Neil R. Ormos, 2022/05/08
- Re: [gawk-devel] MPFR thoughts, arnold, 2022/05/09
- Re: [gawk-devel] MPFR thoughts, Eric Pruitt, 2022/05/09