Re: libgcc update ... to 4.9?
On Thursday August 21 2014 02:08:39 René J.V. Bertin wrote: > On Aug 21, 2014, at 02:00, Brandon Allbery wrote: > > > So, for what it's worth, just did a selfupdate and upgrade outated. > > > > It built libgcc from source, without even checking for an archive. I do not > > force source builds or use nonstandard prefixes, and in fact I do get many > > things from archives. > > So that makes us 2. For now I've managed to downgrade the gcc4[89] portfiles > to the previous versions, to keep gcc48 and libgcc at the same version. I'll > see if I can have a go at obtaining a distfile download log, one of these > days. Doh, duh, bummer, etc. I had the universal libgcc variant installed. Apparently I must have tried at some point if a universal compiler was required or better for producing 32bit code, and I forgot to "downgrade" the libgcc port. Mea culpa! R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 22, 2014, at 5:56 PM, René J.V. Bertin wrote: > Yes, I should have looked more closely at that log before uploading it. I > surely must have relaunched the upgrade procedure without cleaning > libgcc/gcc49 properly. > Sure, that unfinished build would explain why that 2nd attempt didn't try to > download a binary package, but why was a build from source launched at the > 1st attempt? We'd have to see a clean log. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
> On Aug 22, 2014, at 4:56 PM, René J.V. Bertin wrote: > > Where the build system writes files outside of the /opt/local/var/build? > Could you give an example of a really bad one? > That shouldn't be that usual, though some build systems might try to use /tmp/ or /var/tmp, instead of using the $TMPDIR variable we have set up. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 22, 2014, at 22:59, Clemens Lang wrote: > binary archives. In fact, since it picked up an unfinished build and > continued it, this may well be the reason for not using binaries. Yes, I should have looked more closely at that log before uploading it. I surely must have relaunched the upgrade procedure without cleaning libgcc/gcc49 properly. Sure, that unfinished build would explain why that 2nd attempt didn't try to download a binary package, but why was a build from source launched at the 1st attempt? >> Surely, but how many such build systems does MacPorts carry?. > > Hundreds of them. Even thousands. Where the build system writes files outside of the /opt/local/var/build? Could you give an example of a really bad one? > > Correct, pretty much all ports currently use root privileges during > installation, because the change file owners and modes. That could only > prevented by using something like fakeroot, which would have to be ported to > OS X first. To my knowledge, fakeroot does its name justice, and does not allow one to get real root privileges... > > Did you mean "/opt/local" here, not "/usr/local"? And other than that, again, No, I also have a /usr/local . > make install DESTDIR=$destroot with root privileges. And again, looking at > your requirements makes me think you should really use a non-root installation > of MacPorts. No, I don't think so. I do have things in MacPorts that require root privileges, so I decided that putting a sudo in front of `port selfupdate` and `port install/uninstall` isn't that cumbersome. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
Hi,
> I still had the log from the attempt to install libgcc 4.9; it's attached.
As Joshua already told you, this doesn't contain the reason for not using
binary archives. In fact, since it picked up an unfinished build and
continued it, this may well be the reason for not using binaries.
> Surely, but how many such build systems does MacPorts carry?.
Hundreds of them. Even thousands.
> And in a sense I want the build system to be able to read my files. I
> no longer run `port install` as myself because too many ports need actual
> root privileges during install, but for the rest I like to have the build
> tree to be mine. For a number of ports (like kdelibs4), the work source
> directory is actually a symlink to a directory in one of my own working
> directories.
Correct, pretty much all ports currently use root privileges during
installation, because the change file owners and modes. That could only
prevented by using something like fakeroot, which would have to be ported to
OS X first.
Note that the sandboxing was specifically introduced to lower the risk in
doing that, because even with root privileges, build system can not modify
files outside of their destroot directory.
> Takes a bit of discipline (to avoid reverting my changes to stock) but it
> greatly increases turn-over once you master it. For cmake projects, I can
> simply do a make in the lowest build directory holding my changes that has
> a CMakeLists.txt, and then do a `make install/fast` from there to install
> the new files directly into ${prefix}.
Sounds like what you really want is a non-root installation of MacPorts. You
can configure MacPorts with --with-no-root-privileges.
> (I'm much more concerned about what could happen during an install, and not
> so much to my files but to system files. Which is why my whole /usr/local
> tree is owned by me and not by root, and why I ran `port install` as myself
> for so long.)
Did you mean "/opt/local" here, not "/usr/local"? And other than that, again,
sandboxing is there for exactly this reason, to reduce the risk of running
make install DESTDIR=$destroot with root privileges. And again, looking at
your requirements makes me think you should really use a non-root installation
of MacPorts.
--
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
libgcc update ... to 4.9?
> On Aug 21, 2014, at 12:17, Clemens Lang wrote: > >> I couldn't see anything that would prevent the use of binary archives. Can >> you >> attach the main.log of an attempt to install a package that should use binary >> archives, but didn't? > > I still had the log from the attempt to install libgcc 4.9; it's attached. The log shows that the configure phase was already complete. So it picked up from where it left off and continued on with the build phase. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
Hi,
On Aug 21, 2014, at 12:17, Clemens Lang wrote:
>> I think my macports.conf file fulfils those conditions, but just in case you
>> forgot something, I've attached it.
>
main.log.bz2
Description: BZip2 compressed data
> I couldn't see anything that would prevent the use of binary archives. Can you
> attach the main.log of an attempt to install a package that should use binary
> archives, but didn't?
I still had the log from the attempt to install libgcc 4.9; it's attached.
> You should enable the sandbox again, since the problem has been fixed.
Ok.
> Note that setting macportsuser to the name of your account defeats the
> purpose of the user. Using a separate unprivileged user here makes sure no
> build system can modify (or even read) your files. Your configuration is
> insecure and should be avoided.
Surely, but how many such build systems does MacPorts carry?. And in a sense I
want the build system to be able to read my files. I no longer run `port
install` as myself because too many ports need actual root privileges during
install, but for the rest I like to have the build tree to be mine. For a
number of ports (like kdelibs4), the work source directory is actually a
symlink to a directory in one of my own working directories. Takes a bit of
discipline (to avoid reverting my changes to stock) but it greatly increases
turn-over once you master it. For cmake projects, I can simply do a make in the
lowest build directory holding my changes that has a CMakeLists.txt, and then
do a `make install/fast` from there to install the new files directly into
${prefix}.
(I'm much more concerned about what could happen during an install, and not so
much to my files but to system files. Which is why my whole /usr/local tree is
owned by me and not by root, and why I ran `port install` as myself for so
long.)
R.___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
Hi, > I think my macports.conf file fulfils those conditions, but just in case you > forgot something, I've attached it. I couldn't see anything that would prevent the use of binary archives. Can you attach the main.log of an attempt to install a package that should use binary archives, but didn't? > It still contains the commented-out lines from when I had it point to the > actual install location, and it has the sandbox disabled as at some time > that was required to avoid issues with /opt/local being a symlink. You should enable the sandbox again, since the problem has been fixed. > Otherwise, the only thing that maybe isn't "stock" is the macports user but > that shouldn't influence the decision to install from available binary > packages, I guess. Note that setting macportsuser to the name of your account defeats the purpose of the user. Using a separate unprivileged user here makes sure no build system can modify (or even read) your files. Your configuration is insecure and should be avoided. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 21, 2014, at 00:37, Ryan Schmidt wrote: > > On Aug 20, 2014, at 4:05 AM, René J.V. Bertin wrote: > >> In fact, is there a way to get those installed manually, should `port` not >> pick them up for whatever reason? For ports that take as long to build as >> gcc or libgcc, replacing the build time with a bit of terminal exercise is >> still an immense gain of time. > > There are several reasons why MacPorts would not attempt to download a binary: > > * your prefix is not /opt/local > * your applications_dir is not /Applications/MacPorts > * your frameworks_dir is not /opt/local/Library/Frameworks > * the port prohibits the use of binaries > * you've edited macports.conf and requested source builds only > > There may be other conditions I'm forgetting. > I think my macports.conf file fulfils those conditions, but just in case you forgot something, I've attached it. It still contains the commented-out lines from when I had it point to the actual install location, and it has the sandbox disabled as at some time that was required to avoid issues with /opt/local being a symlink. Otherwise, the only thing that maybe isn't "stock" is the macports user but that shouldn't influence the decision to install from available binary packages, I guess. Or I should never benefit from those, and yet, fortunately, I do. macports.conf Description: Binary data ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 20, 2014, at 7:00 PM, Brandon Allbery wrote: > It built libgcc from source, without even checking for an archive. I do not > force source builds or use nonstandard prefixes, and in fact I do get many > things from archives. This makes me think license or etc. may be incorrect, > or at least suboptimal. The license allows distribution: $ ~/macports/base/portmgr/jobs/port_binary_distributable.tcl -v libgcc "libgcc" is distributable The license checks are only done on the server. MacPorts base doesn't know about licenses, and will check the server for the availability of a binary, if the other conditions are met. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 21, 2014, at 02:00, Brandon Allbery wrote: > So, for what it's worth, just did a selfupdate and upgrade outated. > > It built libgcc from source, without even checking for an archive. I do not > force source builds or use nonstandard prefixes, and in fact I do get many > things from archives. So that makes us 2. For now I've managed to downgrade the gcc4[89] portfiles to the previous versions, to keep gcc48 and libgcc at the same version. I'll see if I can have a go at obtaining a distfile download log, one of these days. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Wed, Aug 20, 2014 at 6:37 PM, Ryan Schmidt wrote: > > On Aug 20, 2014, at 4:05 AM, René J.V. Bertin wrote: > > > In fact, is there a way to get those installed manually, should `port` > not pick them up for whatever reason? For ports that take as long to build > as gcc or libgcc, replacing the build time with a bit of terminal exercise > is still an immense gain of time. > > There are several reasons why MacPorts would not attempt to download a > binary: > So, for what it's worth, just did a selfupdate and upgrade outated. It built libgcc from source, without even checking for an archive. I do not force source builds or use nonstandard prefixes, and in fact I do get many things from archives. This makes me think license or etc. may be incorrect, or at least suboptimal. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 20, 2014, at 4:05 AM, René J.V. Bertin wrote: > In fact, is there a way to get those installed manually, should `port` not > pick them up for whatever reason? For ports that take as long to build as gcc > or libgcc, replacing the build time with a bit of terminal exercise is still > an immense gain of time. There are several reasons why MacPorts would not attempt to download a binary: * your prefix is not /opt/local * your applications_dir is not /Applications/MacPorts * your frameworks_dir is not /opt/local/Library/Frameworks * the port prohibits the use of binaries * you've edited macports.conf and requested source builds only There may be other conditions I'm forgetting. If all the conditions are met, though, MacPorts will attempt to fetch a binary. If it fails, it will attempt to build from source. Reasons for the fetch to fail include: * no binary is available for the given OS and arch and variant combination * your network is having problems * our server is down Reasons why a binary might not be available include: * the combination of licenses of the port and all its dependencies does not permit binary redistribution * the port or one of its dependencies does not build * our buildbot is having problems ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9? (and of binary packages and MacPorts install locations)
Hi, > > Is it possible that with the latest selfupdate, changes were included to > > the sandboxing mechanism that further interfere with the > > possibility/transparence of having /opt/local be a symlink to MacPort's > > true location? > > I'm not sure. You'd have to ask Cal. No. In fact, a recent update fixed that configuration, since it was previously broken. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9? (and of binary packages and MacPorts install locations)
On Aug 20, 2014, at 5:02 AM, René J.V. Bertin wrote: >>> Would it at least be possible to provide a binary port for libgcc, to avoid >>> having to build (a large part of) 2 gcc versions? >> >> There already are binary archives, at least for Intel 64. >> >> http://packages.macports.org/libgcc/ > > Indeed there are. Mystery then why yesterday's upgrade process insisted on > installing the port from source (including gcc 4.8.3). > > Is it possible that with the latest selfupdate, changes were included to the > sandboxing mechanism that further interfere with the possibility/transparence > of having /opt/local be a symlink to MacPort's true location? I'm not sure. You'd have to ask Cal. I don't suppose you set +universal in variants.conf, or anything like that? What do you see if you run `sudo port -d archivefetch gcc48`? I've attached my log for reference. vq gcc48_archivefetch.log Description: Binary data ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9? (and of binary packages and MacPorts install locations)
On Aug 20, 2014, at 5:02 AM, René J.V. Bertin wrote: > > Is it possible that with the latest selfupdate, changes were included to the > sandboxing mechanism that further interfere with the possibility/transparence > of having /opt/local be a symlink to MacPort's true location? I have a MacPorts installation that uses an /opt/local symlink and it doesn't have a problem getting/using binaries. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 19, 2014, at 4:25 PM, René J.V. Bertin wrote: > > Would it at least be possible to provide a binary port for libgcc, to avoid > having to build (a large part of) 2 gcc versions? If it is possible to provide a binary, it is done automatically. It looks like binaries for libgcc do exist. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 19, 2014, at 5:25 PM, René J.V. Bertin wrote: > That ticket is about how compiler ports shouldn't install their own libstdc++ > but use the system one. Skim through to the end. It concluded with libstdc++ being split out into the libstdcxx port. Later Jeremy added more support libraries and renamed it libgcc. > Would it at least be possible to provide a binary port for libgcc, to avoid > having to build (a large part of) 2 gcc versions? There already are binary archives, at least for Intel 64. http://packages.macports.org/libgcc/ vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libgcc update ... to 4.9?
On Aug 19, 2014, at 2:05 PM, René J.V. Bertin wrote: > Doing a belated selfupdate, I see that libgcc has been bumped to 4.9x (and > fails to build with Apple's gcc-4.2). However, I'm still using gcc48, with no > intention to upgrade it just now. Am I obliged to use a 4.9 libgcc - is that > even possible with gcc-4.8? Yes, it is very possible and quite intentional. We (read: Jeremy) divorced the GCC support libraries from the compilers some time ago. http://trac.macports.org/ticket/35770 vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
libgcc update ... to 4.9?
Hi, Doing a belated selfupdate, I see that libgcc has been bumped to 4.9x (and fails to build with Apple's gcc-4.2). However, I'm still using gcc48, with no intention to upgrade it just now. Am I obliged to use a 4.9 libgcc - is that even possible with gcc-4.8? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
