Re: We will need an isolated gcc c++11 bootstrap compiler
Confirmed that Leopard i386, at least, can make the steps: system compiler -> gcc-6 self-contained -> gcc11/libgcc11 without any trouble. Tiger i386 testing is underway and then PPC. There is reasonable hope that in due course the entire platform list from Tiger to the current will standardize on gcc11/libgcc11. Along a similar path, we could also use the self-contained gcc6 on 10.4 through 10.6 to directly build a bootstrap version of clang-3.8 or 4.0 or 7.0 for example (linking against libstdc++), skipping clang-3.4, clang-3.7, and the partly-compromised libcxx without thread_local support we build now, and then use that bootstrap clang to directly build libcxx with thread_local support from the start, and go right to clang-9.0. system roots -> gcc6 self-contained -> clang-bootstrap -> libcxx +emulated_tls -> clang-9.0. Apparently clang-4 when linked against libstdc++ is set to look in it's own tree for libstdc++ first, so it could be self-contained if we copy in libstdc++ from gcc6-bootstrap after it is built. That potentially gets us out of a whole lot of "clang_dependency" hell. Ken On Tue, Jul 6, 2021 at 12:33 AM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > gcc11+ requires a c++11 compiler to build, and won't build with older > clang versions for other reasons besides c++11 capability. > > So to bring the older systems up to parity with current and supported gcc > versions, and hopefully have them standardize on libgcc11 to make it all > easier on everyone, I'm going to need to create a stand-alone gcc compiler > that is self-contained with it's own libraries to use as a bootstrap. > > I'm thinking this will either be gcc5 or gcc7 at present as they are both > capable and very easy to build on every system using system roots. > > The bootstrap gcc5 or gcc7 will be tucked away somewhere off the beaten > path, and used only to build gcc11/libgcc11 on older systems, and other > similar things that might be needed for bootstrapping. > > Ken >
Re: delete in post-destroot is ineffective, how to make it effective?
On 2021-07-12 11:29, Rainer Müller wrote:
On 12/07/2021 11.49, Jim DeLaHunt wrote:
I am breaking a single upstream codebase into subports. I want each
subport to contribute some of the overall complement of files. But the
"make install" of the codebase installs more files than I want. Thus I
think the right thing to do is to declare a post-destroot which delete
the excess files from each subport.
Sounds reasonable, but be aware … With the same
build command, each subport will take the same time to compile from
source, even if you later only need a few files in destroot. Therefore
it would still be a good idea to only build what you need for each subport.
I understand. I have modified the configure args for each subport to
prevent what build activity I can. Unfortunately, the upstream code does
not give me configure args to prevent building these particular items.
My Portfile has an entry like this:
post-destroot {
set sharedir ${prefix}/share
delete ${prefix}/lib/libfreeciv.a
delete ${sharedir}/doc ${sharedir}/man ${sharedir}/locale
}
At this point, the files are still not installed on the system, but
reside in the staging directory named ${destroot}, which is at
work/destroot/ as you already found out below.
You need to use absolute paths ${destroot}${prefix}/... here. ${prefix}
is always an absolute path, that's why it can be combined without an
explicit separator. For example, it should look like this:
delete ${destroot}${prefix}/lib/libfreeciv.a
But, when I run "sudo port destroot freeciv-server", then look at what I
believe is the destroot:
ls $(port work freeciv-server)/destroot/opt/local/share
the directories which I wanted to delete are still present.
I look in the main.log for this subport. I don't see any diagnostics
from those delete directives.
This was an attempt to delete files directly from the prefix, which is
/opt/local by default. But trying to delete non-existing files will not
result in an error. Therefore it silently passed doing nothing.
Thank you for the help. I figured it out. It was worse than I thought.
The delete was not just effective, it was _too_ effective! It was
deleting parts of my live installation: /opt/local/share/doc for all
ports, /opt/local/share/man for all man pages, etc. It's at moments like
this that I'm glad to have good backups from which to restore the parts
I blew away.
What I missed is that "delete" operates in the context of the entire
filesystem, not of the destroot path. Thus, it is very important to
include ${destroot} at the start of every path I pass to "delete".
For example,
post-destroot {
set sharedir ${destroot}${prefix}/share
delete ${destroot}${prefix}/lib/libfreeciv.a
delete ${sharedir}/doc ${sharedir}/man ${sharedir}/locale
}
I can now delete files as needed from the destroot. I now get to
encounter the next obstacle. :-)
Thank you for the help, Rainer! Best regards,
—Jim DeLaHunt
Re: delete in post-destroot is ineffective, how to make it effective?
On 12/07/2021 11.49, Jim DeLaHunt wrote:
> I am breaking a single upstream codebase into subports. I want each
> subport to contribute some of the overall complement of files. But the
> "make install" of the codebase installs more files than I want. Thus I
> think the right thing to do is to declare a post-destroot which delete
> the excess files from each subport.
Sounds reasonable, but be aware that subports in MacPorts do not work
like splitting a package with .rpm or .deb. These other systems compile
once and then sort the files into different binary packages.
But with MacPorts, each subport will be built separately. With the same
build command, each subport will take the same time to compile from
source, even if you later only need a few files in destroot. Therefore
it would still be a good idea to only build what you need for each subport.
> My Portfile has an entry like this:
>
> post-destroot {
> set sharedir ${prefix}/share
> delete ${prefix}/lib/libfreeciv.a
> delete ${sharedir}/doc ${sharedir}/man ${sharedir}/locale
> }
At this point, the files are still not installed on the system, but
reside in the staging directory named ${destroot}, which is at
work/destroot/ as you already found out below.
You need to use absolute paths ${destroot}${prefix}/... here. ${prefix}
is always an absolute path, that's why it can be combined without an
explicit separator. For example, it should look like this:
delete ${destroot}${prefix}/lib/libfreeciv.a
> But, when I run "sudo port destroot freeciv-server", then look at what I
> believe is the destroot:
>
> ls $(port work freeciv-server)/destroot/opt/local/share
>
> the directories which I wanted to delete are still present.
>
> I look in the main.log for this subport. I don't see any diagnostics
> from those delete directives.
This was an attempt to delete files directly from the prefix, which is
/opt/local by default. But trying to delete non-existing files will not
result in an error. Therefore it silently passed doing nothing.
Rainer
delete in post-destroot is ineffective, how to make it effective?
I have encountered another obstacle as a Portfile newbie.
I am breaking a single upstream codebase into subports. I want each
subport to contribute some of the overall complement of files. But the
"make install" of the codebase installs more files than I want. Thus I
think the right thing to do is to declare a post-destroot which delete
the excess files from each subport.
My Portfile has an entry like this:
post-destroot {
set sharedir ${prefix}/share
delete ${prefix}/lib/libfreeciv.a
delete ${sharedir}/doc ${sharedir}/man ${sharedir}/locale
}
But, when I run "sudo port destroot freeciv-server", then look at what I
believe is the destroot:
ls $(port work freeciv-server)/destroot/opt/local/share
the directories which I wanted to delete are still present.
I look in the main.log for this subport. I don't see any diagnostics
from those delete directives.
How can I remove the unwanted files from what the port installs? How can
I make these delete directives effective?
Thank you in advance for your help. Best regards,
—Jim DeLaHunt
