Re: remove intl/ directory?
Hi Bruno,
> On 19 Jun 2022, at 01:32, Bruno Haible wrote:
>
> Iain Sandoe wrote:
>> As a maintainer for GCC on a non-glibc system, I would:
>> (b) not want to [force] add a shared lib dependency for my downstream.
>
> In order to avoid shared libs, the user merely has to pass the option
> '--disable-shared' to GNU gettext's configure.
Well, we try to make things easy for end-users, so actually the objective would
be that (for those who are prepared to download a pre-built binary) that they do
not have to find and build _any_ other libs.
“Distributions” might choose to go the shared library route - on the basis that
they have already presumably automated the installation of dependencies
- so it’s just that the user has to wait a little longer for the install...
For people intending to build from source, we can try to automate with scripts
and pre-fetching of prerequisites etc. .. OTOH GCC is complex enough in its
own right, it’s better to keep things as simple as possible.
>
>> - so, please could we follow the pattern for GMP et. al. where the library
>> can be provided with —with-intl= pointing to an installation
>
> That convention is already built-in in the gettext.m4 macro; the option is
> called --with-libintl-prefix there.
>
>> , or be built in-tree by symlinking an approved version into the GCC tree.
>
> If you are referring to the sentence found in the GCC documentation for
> ISL, MPFR, etc.
> "If an isl source distribution is found in a subdirectory of your GCC
> sources named isl, it will be built together with GCC."
yes, exactly - that is usually how I build GCC - in addition to the
simplification of distributing a built compiler, it also has the advantage that
the same deps that one tested with are fixed into the binary.
> I believe that this can be achieved easily by adding a few lines to the
> Makefile.def, such as:
>
> host_modules= { module= gettext-runtime; no_install=true;
>extra_configure_flags='--disable-shared';
>lib_path=intl/.libs; };
>
> The symlink 'gettext-runtime' will need to point to the 'gettext-runtime'
> *subdirectory* of an unpacked GNU gettext tarball.
Thanks, that’s very helpful information - it could be something to trial
relatively
easily.
** NOTE: this is not a GCC-only decision, intl is used by a number of other
pieces
(GDB, GDB-server, binutils etc. etc) These projects share the top-level build
infrastructure — [see Makefile.def and grep intl].
I suppose one could try s/intl/gettext-runtime/ and then rebuild the top-level
makefiles..
thanks,
Iain
save/relocate/restore call stack or coroutine?
Hi! Purely theoretical question here. :) Many people, including myself, keep falling into this trap: https://www.reddit.com/r/cpp/comments/eewqwc/serializable_coroutines_in_c_gameplay_code/ Which is that they take the fibers/coroutines to implement some logic with wait/blocking capability, and, because there is a state object (eg ucontext_t) and an explicitly allocated stack frame, they expect to be able to save/restore it along with any other save data. I believe this even worked in some limited scenarios in pre-ASLR era, but today they face the fact that the call stack needs to be somehow "relocated" to be loaded on a different process. I looked around to see what gcc technologines are available to help with that, and what I've found, is: - backtrace() can be used to identify all return addresses on stack, and to patch them up. - Named address spaces __seg_fs, __seg_gs can be used to make some pointers relocation- friendly. Unfortunately there seem to be no way to build the entire compilation unit with __seg_fs being a default address space, and also there seem to be no conversion between __seg_fs and normal pointers (by adding/subtracting rdfsbase on a conversion). - Stack maps: https://www.mail-archive.com/gcc@gcc.gnu.org/msg77319.html were considered too difficult to implement: https://www.mail-archive.com/gcc@gcc.gnu.org/msg77317.html and AFAICS are still not implemented. They could help to identify all pointers to heap objects and relocate them, but I wonder if they are only considered for strongly-typed languages, and not for C/C++. So the question is: how realistic is to expect that the call stacks would be saveable/relocatable one day? How far are we from that point? It looks like all the needed technologies already either exist or at least are considered for an implementation. Or am I missing much more unsolvable problems? Or maybe there is already some other way of doing that? :)
Re: remove intl/ directory?
Hi Bruno,
> On 19 Jun 2022, at 09:40, Iain Sandoe via Gcc wrote:
>
>> On 19 Jun 2022, at 01:32, Bruno Haible wrote:
>>> - so, please could we follow the pattern for GMP et. al. where the library
>>> can be provided with —with-intl= pointing to an installation
>>> , or be built in-tree by symlinking an approved version into the GCC tree.
>> I believe that this can be achieved easily by adding a few lines to the
>> Makefile.def, such as:
>>
>> host_modules= { module= gettext-runtime; no_install=true;
>> extra_configure_flags='--disable-shared';
>> lib_path=intl/.libs; };
>>
>> The symlink 'gettext-runtime' will need to point to the 'gettext-runtime'
>> *subdirectory* of an unpacked GNU gettext tarball.
>
> Thanks, that’s very helpful information - it could be something to trial
> relatively
> easily.
So, indeed, part of this is quite straight forward - we can amend the
Makefile.def
to specify that GCC should use gettext-runtime (it will be used if the
directory is
present, otherwise there will be no intl support).
The tricky part is that we need to use the runtime ‘uninstalled’, and here is
where
intl is helpful - it provides a ‘config.intl’ that can be sourced via
gettext-sister.m4
to provide the neccessary configure input to directories that want to use intl.
I have hacked a change to gettext-sister.m4 that fishes the same information out
of gettext-runtime/Makefile (as configured in $build) - obviously this is going
to be
fragile w.r.t different versions of gettext-runtime (so I am not suggesting
this is a
viable patch) - simply something to illustrate what needs to be figured out.
So - the changes are in Makefile.def and config/gettext-sister.m4 (the patch
includes
the regenerated files for convenience of use).
I tried this with gettext-0.21 on macOS 10.15 and, AFAICT, it DTRT - but needs
work
to resolve the main point above.
This has been tried with / without deleting intl; from the GCC perspective it
works the
same both ways, except that there’s a redundant build of intl when
gettext-runtime is
present (but it does mean that the other packages - GDB et. al, are not
changed).
I’d be interested in your ideas for how to solve the ‘uninstalled’ use.
Iain
P.S. I am slighty surprised that configuring with —disable-java does not appear
to stop
the on-screen popup appearing that tells me I need to install Java to use this
… that
would be an irritation when using this on a headless box.
0001-config-Quick-hack-to-try-using-gettext-runtime-in-pl.patch
Description: Binary data
gcc-13-20220619 is now available
Snapshot gcc-13-20220619 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20220619/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 4390e7bfbc641a52c6192b448768dafdf4565527 You'll find: gcc-13-20220619.tar.xz Complete GCC SHA256=90d2f107b82ca3a634081ee8f31d2e80bb27ce254f868aef2ac13e2a4d01b7b4 SHA1=000a3ed3d4fc3adedb66db50acd18bd88410999f Diffs from 13-20220612 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
