Depending on the environment it is installed in, the default CUDA
installation used by NVHPC can differ. This configuration is discovered and
stored by a post-installation hook in an rc file which is then read by
NVHPC's nvc++ compiler before it always executes.

There are no environment variables here but the version of CUDA available
will change according to what options were passed to the post installation
hook.

On Thu, 15 Jun 2023, 23:27 Stephen Kelly via SG15, <sg15_at_[hidden]>
wrote:

>
> On 15/06/2023 21:51, René Ferdinand Rivera Morell wrote:
> > On Thu, Jun 15, 2023 at 3:16 PM Stephen Kelly <steveire_at_[hidden]>
> wrote:
> >>
> >> I have seen the suggestion of a command line option, and the option of
> a file next to the tool, but I haven't seen a suggestion of what Qt does
> for the last 11 years for plugin loading, which has many of the same
> challenges with cross-compiling etc. That is - embed the metadata into the
> binary itself and read the data from a readonly section of the binary:
> >>
> >> $ objcopy
> /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqtiff.so /dev/null
> --dump-section .qtmetadata=/dev/stdout
> >> QTMETADATA
> !�x1org.qt-project.Qt.QImageIOHandlerFactoryInterfacekQTiffPlugin�dKeys�dtiffctifiMimeTypes�jimage/tiffjimage/tiff
> >>
> >>
> >> I think in Qt 6 it works the same way, but the plugins have cbor data
> encoded in them. This allows Qt to know whether a plugin can load .jpg or
> .png etc.
> >>
> >>
> https://lists.qt-project.org/pipermail/development/2012-February/001827.html
> >>
> >> You could try to pursue something similar, but it would assume/require
> a way to read data sections from a binary.
> > That's an interesting approach. Does that mean you would need
> > different methods to get the data based on the environment?
>
>
> Different methods based on the file. I guess that's what you mean by
> environment. ie, if you have an elf file, you need some tool (or C++
> API/other language API/custom parser for the binary format) which can
> understand elf, regardless of the platform you are running on.
>
> Qt doesn't operate on all of the platforms that are relevant for C++,
> but it has ways to extract the data from ELF, PE/COFF and Mach-O files.
> It also has a "slow fallback" where it just searches for a magic string
> followed by the data. See qlibrary.cpp if you can just look at Qt code
> to see how it's done in code.
>
> The things that I think could kill this idea are
>
> 1) Requiring a different way to access the metadata per binary format
>
> 2) The binary format needing a way to have the metadata retrievable
> within it without affecting the running of the binary.
>
> I have no idea whether either is a real problem.
>
> > And how do
> > those methods work if the binary is for another environment?
>
>
> In the case of Qt, the ELF files are only loaded on an elf platform, but
> (I assume) there is no reason you can't have an ELF parser on Windows or
> a PE/COFF parser on Linux?
>
> It would also be possible to have a proof of concept tool written in
> some widely available language which abstracts those differences in
> binary format away (for known platforms) and dumps the json/cbor data.
>
>
> > Something else that a friend brought up is that the introspection
> > information may depend on environment information that is only
> > available at install time. I.e. that it can't be fixed data.
>
>
> I think D2717 so far only has spec for outputting the versions of
> metadata, so I'm not sure what it could contain that would be dependent
> on environment variables. Do you have an example?
>
> I guess a compiler which can be used as a cross-compiler (clang or QNX
> QCC) could have different capabilities (availability of thread_local or
> C++26, for example) depending on what it is targetting, but I'm sure
> there's some way of expressing that statically.
>
> Thanks,
>
> Stephen.
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>