[ I found this in my outgoing folder; ahem. ]
On Tue, 31 Dec 2019, Mark Linimon wrote:
> As of the following commit, lang/gcc6 is no longer supported:
>
> https://svnweb.freebsd.org/ports/head/Mk/bsd.gcc.mk?revision=521584
GCC 6 hasn't been supported upstream for over a year (end of life)
and
On Thu, 26 Dec 2019, Mark Millard wrote:
> I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an
> ELFv1 clang environment) and it reported (listing just one of the
> examples that pointed to vec_step):
I maintain this is a bug in clang which should be address there.
https://bugs.free
On Sun, 28 Jul 2019, Kevin Oberman wrote:
> The description of the commit states:
>
> This includes ports
> - with USE_GCC=yes or USE_GCC=any,
> - with USES=fortran,
> - using Mk/bsd.octave.mk which in turn features USES=fortran, and
> - with USES=compiler specifying openmp, nestedfct, c11, c+
On Sat, 27 Jul 2019, Kevin Oberman wrote:
> Today I was hit with 226 ports needing update. With one exception, all
> were the result of the bump or the default gcc version to 9.1. The
> problem is that 9.1 was not installed first, so over 43 of these ports
> were rebuilt with the exact same comp
In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237688 we had
a user report against lang/gcc* ports that could be traced back to
a certain functionality (option) in another port (devel/binutils)
missing.
In pseudo-code this could be addressed as follows in lang/gcc*
.if $(binutils built
On Mon, 8 Apr 2019, Tijl Coosemans wrote:
>> This patch make 3 the default for gfortran.
> s/make/makes/ but otherwise the patch looks fine.
Thank you, Tijl.
I updated lang/gcc8 (including bumping its PORTREVISION) and will
apply the same to lang/gcc8-devel next, and then lang/gcc9-devel
so lang/
Hmm, I received zero feedback on this proposal, when it appeared
important for a number of users.
What's your take, Andreas, Tijl (your patch essentially with a bit
of an updated description), and toolchain?
Gerald
On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
> Hi Tijl, hi everyone,
>
Hi Tijl, hi everyone,
and let me add Andreas who has been helping on the GCC side (both
ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
And first of all, let me apologize. Clearly the experience both Tijl
as a contributor made, as well as the one some of our users inclu
On Tue, 26 Feb 2019, Tobias Kortkamp wrote:
> Added in https://svnweb.freebsd.org/changeset/ports/493984
You. Rock. Tobias.
Thank you!
Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscr
Hi everyone,
the next version of Wine (incl. the next bi-weekly snapshot) is
going to have a dependency on a new package, FAudio:
https://github.com/FNA-XNA/FAudio/
That's a C99 library which builds with CMake and depends only on
SDL2 (ideally 2.0.9). There are special build options availa
On Jun 25 2016 Richard Gallamore wrote:
> When using USE_GCC= 5+, errors occur because this USE only sets
> build and run time dependency, and not lib dependency.
>
> Error: /usr/local/bin/ann_in is linked to
> /usr/local/lib/gcc5/libgfortran.so.3 from lang/gcc but it is not declared as
> a depen
On Fri, 14 Apr 2017, Alexander Kabaev wrote:
> it was suggested multiple times that the whole fixinc step is
> ultimately harmful and serves no useful purpose and probably should be
> disabled in built packages outright. Is there a reason not to do it?
> Even Redhat appears to do the slimming in th
Am 3. Juli 2017 13:30:13 GMT+08:00 schrieb Mark Millard :
>[More on the behavior: it is more complicated than
>previously shown.]
It's actually pretty simple (I think). Mk/bsd.gcc.mk only uses lang/gcc* ports
that represent releases, not lang/gcc*-devel that represent snapshots.
So your patch
Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard :
>I'm not currently set up to run more than head on
>any of amd64, powerpc64, powerpc, aarch64, or armv6/7
>(which are all I target). And I'm in the middle of
>attempting a fairly large jump to head -r320458 on
>those.
Oh, then I had misu
Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard :
>A primary test is building lang/gcc5-devel under release/11.0.1
>and then using it under stable/11 or some draft of release/11.1.0 .
Thank you, Mark. Let me know how it went. In the meantime I'll prepare the
change for gcc5 itself.
>I
Hi everyone,
I am testing a patch for gcc5-devel right now that will disable fixincludes (or
rather its fixed files) being packaged.
Should that work fine for you, I will push this back to gcc5 the following days.
That said, the change that triggered this is what I would expect on CURRENT,
not
On Sun, 28 May 2017, Gerald Pfeifer wrote:
> What do you guys think about the following patch for emulators/wine
> to help clarify this?
I now applied this to help clarify for others (just changing
lang/i386-wine to emulators/i386-wine - too much lang/gcc* work
recently ;-).
this port for 32-bit Windows binaries in an i386 environment or
+64-bit Windows binaries in an amd64 environment; use lang/i386-wine
+for 32-bit Windows binaries in an amd64 environment.
+
WWW: http://www.winehq.org/
Gerald Pfeifer
___
freebsd-ports@fre
On Sun, 23 Apr 2017, Tijl Coosemans wrote:
>> [ https://reviews.freebsd.org/D10357 ]
> Yes, but in my opinion we should stop relying on upstream build systems
> to get stripping right and let bsd.port.mk strip ELF files after staging.
> It's less work for maintainers. Then instead of stripping, bs
[ Old thread alert, but still relevant. ]
On Mon, 19 Jan 2015, Tijl Coosemans wrote:
install -m 555 mkheaders
.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/mkheaders
test -z 'strip' || strip
.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freeb
On Thu, 13 Apr 2017, Pedro Giffuni wrote:
> I didn’t want to get into this but the problem is that as part of it's
> build/bootstrapping process, GCC historically takes system headers
> and attempts to “fix” them. I am unsure the fixes do anything at all
> nowadays but the effect is that the compil
On Sat, 11 Mar 2017, Jan Beich wrote:
>> https first for people that run 'make makesum'.
> It was made MITM-friendly sometime ago.
>
> https://svnweb.freebsd.org/changeset/ports/324051
With that, isn't https pretty pointless? I guess I'll leave
things as are, then, for that mirror that offers bot
As some of you may have seen, I have done a bit of work on
bsd.sites.mk recently.
One question I ran into: If a site offers both HTTPS and HTTP,
which of the two do we prefer? (Or do we want to list both?)
Gerald @FreeBSD.org
___
freebsd-ports@freebs
On Fri, 3 Feb 2017, John Marino wrote:
> AFAIK it's not documented, but it's been spoken here quite a few times
> and the result was "try to be nice and if you must use OSVERSION, guard
> it with OPSYS". Anything else is a bug because OSVERSION only makes
> sense with an exact value of OPSYS ("
Hi guys,
I noticed I did fix this on Monday triggered by this mail, but failed
to send my response and explanation. So, here we go...
On Sun, 8 Jan 2017, Adam Weinberger wrote:
>> freebeast(11.0-S)[3] cd /usr/ports/emulators/wine-staging
>> freebeast(11.0-S)[4] sudo make fetch
>> Password:
>> ==
On Sun, 11 Dec 2016, Mark Millard wrote:
> I reported already that devel/kBuild/Makefile has in its
> Makefile:
>
> USE_GCC= any
>
> and devel/kBuild is what causes the lang/gcc* build. (I
> reported more than that but it is the part relevant here.)
I had read that, and I di investigate.
USE_G
Hi Mark,
On Sat, 10 Dec 2016, Mark Millard wrote:
> [Top post of example lack of lang/gcc6-devel vs. lan/gcc6
> substitutability. Context /usr/ports/ at -r428325 (other
> than a few specially controlled items.]
I had another look, and lang/gcc6 and lang/gcc6-devel really are
substitutable in what
On Fri, 25 Nov 2016, Mark Millard wrote:
> I wonder if that leaves lang/gcc and lang/gcc49 as conflicting.
Yes, these two ports conflict for the time being, and are properly
marked as such.
(And I am looking for a more elegant approach going forward, in
particular when we move into GCC 5 territo
On Wed, 20 Apr 2016, Dimitry Andric wrote:
> This is because gcc48's header does not define a whole bunch of
> C99 math functions in the std:: namespace.
> and
> /usr/local/lib/gcc48/include/c++/x86_64-portbld-freebsd9.3/bits/c++config.h
> has:
>
> /* Define if C99 functions or macros in shoul
On Sat, 28 May 2016, Warner Losh wrote:
> armv6*-*-freebsd is only hard float ABI for FreeBSD 11.
:
> Are you saying that we need to get these changes to the ports in place
> to support hard float?
For the record, this has now happened with the great help of
Andreas Tobler (both upstream and in o
On Mon, 13 Jun 2016, Andreas Tobler wrote:
> Should be fixed. I forgot to commit the lang/gcc6 patch.
Thanks, Andreas!
I see this in the lang/gcc6 now (and in case anyone is wondering,
lang/gcc6-devel gets new stuff earlier from upstream, whereas
lang/gcc6 needs to wait for the next release --
On Tue, 22 Jul 2014, Diane Bruce wrote:
> Any chance we could have a script "gfortran" which by default
> ran the default gcc from bsd.default-versions.mk and make.conf ?
I know this took a little, ahem, but what do you think about
the patch below?
With this change, lang/gcc, our canonical GCC po
Hi Rainer,
On Mon, 9 Nov 2015, Rainer Hurling wrote:
> I am using lang/gcc48 for a long time now on FreeBSD 11.0-CURRENT. From
> time to time I have to rebuild the port. This is the first time, that I
> get the following error:
I have no idea where this is coming from. In fact, I rebuilt
the l
On Tue, 7 Apr 2015, Ben Woods wrote:
> It looks like this is a bug which has been reported upstream in the wine
> forums:
> https://forum.winehq.org/viewtopic.php?t=24430&p=99442
Interestingly it only happens on FreeBSD head, though; all other
version appear fine.
Gerald
On Tue, 7 Apr 2015, pkg-fall...@freebsd.org wrote:
> Ident: $FreeBSD: head/emulators/wine-compholio/Makefile 375756
> 2014-12-28 20:39:48Z dbn $
> Log URL:
> http://beefy3.isc.freebsd.org/data/head-i386-default/p383446_s281156/logs/wine-compholio-1.7.40,1.log
> Build URL:
>
On Sunday 2015-01-18 13:01, Tijl Coosemans wrote:
>> Here is the build log:
>>
>> install -m 555 fixinc.sh
>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixinc.sh
>> install -s -m 555 fixincl
>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.
The ports q/a framework has been suggesting this for a while, so
I added INSTALL_TARGET=install-strip to lang/gcc5/Makefile.
Using install-strip for vanilla GCC builds (from source, outside
the FreeBSD Ports framework) works just fine.
In the context of Ports this runs into a permission problem
On Fri, 12 Sep 2014, Andrey Chernov wrote:
>> As I just found, it builds with BOOTSTRAP nice, so apparently clang
>> makes some damage. You can see CFLAGS in the log. Swap is 4GB I think it
>> is large enough. Nothing special otherwise.
> BTW, previous 4.7* as lang/gcc build fine even without BOOTS
Hi Andrey,
On Fri, 12 Sep 2014, Andrey Chernov wrote:
> With recent ports tree on stable-10 i386 attempting to build lang/gcc
> always cause segfault at this place. Log below. Any ideas?
this is actually the primary test platform I use for every single
commit to this port. Plus I've been runni
On Thu, 17 Jul 2014, Lev Serebryakov wrote:
> Maybe, we should encourage ports, which is needed gcc, to use only one
> version? If many ports needs 4.8, maybe, we should bump "any" version to
> 4.8 for gcc-less systems? And move all other versions to 4.8?
I would love to do that, in fact, I hop
On Tue, 1 Jul 2014, Gerald Pfeifer wrote:
>>> It's LOCALBASE that points to /home/gerald/10-i386, so I am really
>>> puzzled about those @unexec rmdir's that want to remove my LOCALBASE.
>> You can try attached patch.
> Cool. That fixes the issue in my t
On Mon, 30 Jun 2014, Antoine Brodin wrote:
>> In my case PREFIX points to /scratch. It's LOCALBASE that points to
>> /home/gerald/10-i386, so I am really puzzled about those @unexec rmdir's
>> that want to remove my LOCALBASE.
>>
>> Why should any port or package meddle with LOCALBASE??
> You can
On Fri, 20 Jun 2014, Antoine Brodin wrote:
>> Build with a non-standard PREFIX and LOCALBASE in /home/gerald/10-i386,
>> make ports builds have been failing with the following for a bit (for
>> lang/gcc49 among others):
>>
>> Running regression-test, checking for orphans, checking pkg-plist.
[ No ideas? Shall I just file a bug report? ]
Build with a non-standard PREFIX and LOCALBASE in /home/gerald/10-i386,
make ports builds have been failing with the following for a bit (for
lang/gcc49 among others):
Running regression-test, checking for orphans, checking pkg-plist.
>
Build with a non-standard PREFIX and LOCALBASE in /home/gerald/10-i386,
make ports builds have been failing with the following for a bit (for
lang/gcc49 among others):
Running regression-test, checking for orphans, checking pkg-plist.
> Checking for pkg-plist issues (check-plist)
==
On Wed, 11 Jun 2014, Antoine Brodin wrote:
>>> ===> Installing ldconfig configuration file
>>> cannot create
>>> $WRKDIRPREFIX/stage/home/gerald/10-i386/libdata/ldconfig/gcc49: No such
>>> file or directory
>>> *** Error code 2
> Please try attached patch.
Thanks, Antoine! This restores
This is a new failure that I found when testing a (trivial) update
to lang/gcc410 with some of my usual scripts:
> Compressing man pages (compress-man)
===> Installing ldconfig configuration file
cannot create $WRKDIRPREFIX/stage/home/gerald/10-i386/libdata/ldconfig/gcc49:
No such fil
On Fri, 9 May 2014, Geoff Speicher wrote:
> Bringing in other parties for feedback, based on their mention in the
> binutils commit (svn link below).
This reminded me of ports/184327: devel/binutils erroneously installs
$PREFIX/include/ansidecl.h.
Please make sure this does not resurface from the
Hi, let me add po...@freebsd.org.
On Mon, 10 Mar 2014, Kenta S. wrote:
> Hi. The GCC update touched the makefiles of net-p2p/libtorrent and
> net-p2p/rtorrent.
>
> When I try to update them with portmaster, I get:
>
> > Compressing man pages (compress-man)
> ===> Installing for libtorrent-
On Thu, 23 Jan 2014, Andrew W. Nosenko wrote:
> But, from my point of view, the problem is not a compiler nor rpath.
> rpath is unneeded indeed, and library indeed may be only one (under
> /lib). The real problem is that this is ancient library, not the most
> recent one.
> They are especially
Wait a minute: is one of yoir ports hard coding lang/gcc46 instead of doing
USE_GCC? If so, here is the bug.
Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "fre
Wait a minute: is one of yoir ports hard coding lang/gcc46 instead of doing
USE_GCC? If so, here is the bug.
Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "fre
the CONFLICTS, please advise so that we can
tighten them.
Gerald
--
Gerald Pfeifer
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-uns
On Fri, 10 May 2013, Dimitry Andric wrote:
> On May 10, 2013, at 18:59, Mikhail T. wrote:
>> Would it be too much work to extend the port-installed compilers the
>> same way gcc-4.2.1 in the base is extended? May be not for gcc4[89],
>> which are complete rewrites, but for 4.[4-7]? If not too di
On Sun, 24 Nov 2013, Dewayne Geraghty wrote:
> Thanks to Gerald for addressing this issue per
> http://svnweb.freebsd.org/ports/head/Mk/bsd.gcc.mk?sortby=date&view=log
> clamav now builds.
Thanks for the confirmation. And sorry for the temporary breakage.
Gerald
_
On Sat, 23 Nov 2013, Baptiste Daroussin wrote:
> This should be a definitive fix:
> http://people.freebsd.org/~bapt/fix-info-subdir.diff
:
> Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I
> have fix in master and will be in 1.2.0 rc2
>
> Can you test?
Yes. I just tested t
On Sat, 23 Nov 2013, Baptiste Daroussin wrote:
> On Sat, Nov 23, 2013 at 01:26:58AM +0100, Gerald Pfeifer wrote:
>> Okay, now I am confused. How can my workaround work for three quadrants
>> of {8.4,9.2} x {amd64,i386} and fail for just one combination?
> Probably one of the p
Okay, now I am confused. How can my workaround work for three quadrants
of {8.4,9.2} x {amd64,i386} and fail for just one combination?
Gerald
On Sat, 23 Nov 2013, Ports-QAT wrote:
> Work around ports infrastructure breakage introduced with staging and
> remove info/gcc46 ourselves.
>
> Reporte
On Fri, 22 Nov 2013, David Naylor wrote:
> The following reports indicate that /usr/local/share/info/gcc46
> (directory) is being left in the working environment and not properly
> cleaned up. Since the ports do not create or use anything in that
> directory I assume this is an issue with the l
On Sat, 16 Nov 2013, Baptiste Daroussin wrote:
> Antoine's patch should be ok for pkg_install, this is what you need for pkgng:
> http://people.freebsd.org/~bapt/info-dir.diff
>
> also 100% untested ;)
This does indeed remove the stray info/ directory, thanks!
I do now see, however, the followin
On Sun, 10 Nov 2013, Antoine Brodin wrote:
> You can try patch at:
> http://people.freebsd.org/~antoine/ports/stage-info_subdir.diff
> (totally untested)
Thanks for looking into this, Antoine. I tested this using
lang/gcc47 and unfortunately info/gcc47 still remains in my
testing.
Gerald
__
On Sat, 9 Nov 2013, Dmitry Marakasov wrote:
> * Ports-QAT (q...@redports.org) wrote:
>
> +gerald@
Staging support broke INFO= here. The INFO= infrastructure should
take care of not leaving anything upon deinstallation and it did
so for years. I looked into fixing this in Mk/bsd.*.mk but failed.
On Tue, 22 Oct 2013, Ports-QAT wrote:
> STAGEify.
> -
>
> Build ID: 20131021182801-5361
> Job owner: ger...@freebsd.org
> Buildtime: 13 hours
> Enddate: Tue, 22 Oct 2013 07:23:12 GMT
>
>
On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
> I've now run ia64 with the above change for over 2 weeks,
> mostly rebuilding ports, etc.
> I didn't see any issues with gcc47.
> So, from my very limited testing,
> gcc47 can be made default.
Thanks for the feedback, Anton! To really make that swi
On Sat, 16 Mar 2013, Bryan Drewery wrote:
>>> So I wonder if there are any side effects or unexpected
>>> effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7?
> I don't think this is working as expected. See also ports/177017 which I
> believe is a bsd.gcc.mk issue and not a pkgng or portmast
On Wed, 6 Mar 2013, Anton Shterenlikht wrote:
> Hi Gerald
>
> amd64 r246552 with clang
clang may be related.
Can you look into what happens here? My tests (with a full build)
definitely have succeeded, and they have actually used clang as cc
on FreeBSD 10.
Is this specific to amd64 for you an
Hi Anton,
On Thu, 7 Feb 2013, Anton Shterenlikht wrote:
> Right now the default GCC is GCC_DEFAULT_VERSION=4.6
> For some time lang/gcc46 doesn't build for me on ia64.
> However, lang/gcc47 and lang/gcc48 do.
>
> There are quite a few ports which I cannot update
> because they depend on lang/
On Tue, 15 Jan 2013, Alex Dupre wrote:
>> to address ports/175072 I finally went ahead with an old plan of
>> mine and broke the binary ecj.jar that is used to build the Java
>> frontend for our GCC 4.6, 4.7 and 4.8 ports out into a separate
>> port: lang/gcc-ecj45.
> Why not using/updating the jav
===
--- gcc-ecj45/Makefile (revision 0)
+++ gcc-ecj45/Makefile (working copy)
@@ -0,0 +1,22 @@
+# Created by: Gerald Pfeifer
+# $FreeBSD$
+
+PORTNAME= gcc-ecj
+PORTVERSION= 4.5
+CATEGORIES=lang java
+MASTER_SITES= ${MASTER_SITE_SOURCEWARE
On Mon, 6 Aug 2012, b. f. wrote:
> Oops: I forgot though, that partly due to this policy of not bumping
> gcc shared library versions, we have some shared libraries in the base
> system that conflict with the shared libraries of the various gcc
> ports, and we have been enforcing the right links by
On Sat, 3 Nov 2012, David Naylor wrote:
> # Executive Summary
>
> Over the past years I have been maintaining the wine-fbsd64 port (see
> http://mediafire.com/wine_fbsd64 for more). The port itself effectively
> does static linking (it bundles all the libraries wine needs) with
> scripts to bo
Hi Ruslan,
On Mon, 17 Sep 2012, Ruslan Mahmatkhanov wrote:
> is there any possibility to also add something like
> USE_FORTRAN_BUILD=[yes|g77|ifort] to make fortran build dependency
> only? Many ports will benefit from this - anything, that depend on
> math/py-numpy for example.
we definitely c
On Mon, 27 Aug 2012, Doug Barton wrote:
> This would seem to be an error in the bsd.gcc.mk logic, or perhaps
> an error in one of the ports' Makefiles, not sure yet. Any chance
> you could look into this?
I had done that when Robert contacted me first and could not find
anything.
Any chance portm
On Tue, 28 Aug 2012, Bryan Drewery wrote:
> I believe this was reported in ports/171135 as well for lang/gcc47.
> Received in private email:
This may or may not be the same issue. In a case like this it
is always possible that one is missing the obvious, but right
now I am simply not seeing it.
On Sun, 29 Jul 2012, Doug Barton wrote:
>> lang/gcc and lang/gcc46 should be fully compatible, without rebuilds
>> necessary. Only when lang/gcc is going to move to GCC 4.7 later this
>> year would I consider that.
> IMO this highlights the issue that unversioned instances of ports that
> really n
On Sun, 29 Jul 2012, Doug Barton wrote:
>>> My suggestion would be to create a directory in $WRKDIR and assign
>>> $TMP (or whatever the right envar is) to it.
>> That could be done, but has one significant drawback: those of us
>> who have /tmp on fastest storage, and $WRKDIR on slower storage,
>
On Tue, 13 Dec 2011, b. f. wrote:
>> Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not
>> seem like this should be too difficult. Just a matter of the right
>> person having the time. Would ports specifying gcc46 need to be
>> touched?
> Gerald had planned to do this after the
On Thu, 16 Feb 2012, b. f. wrote:
>> The main question is why this port (and everythin else with
>> USE_GCC=4.6+) depend on lang/gcc46 and not lang/gcc. Most port
>> users dislike building latest gcc snapshot on a weekly basis.
> Indeed. But (as discussed before on this list), they don't have to,
On Sat, 9 Jun 2012, Doug Barton wrote:
>> Are you saying you actually noticed some leftovers in /tmp, or that
>> there "just" has been more at certain points in time than you would
>> expect?
> I finally had time to watch this closely, and found the culprit(s).
> While building the port creates a l
On Sat, 9 Jun 2012, Doug Barton wrote:
> In an ideal world, we would have separate packages for the runtime libs
> and the build tools so that packages could be more portable, but I would
> imagine that would be a lot of work.
I looked into that last year and found that the FreeBSD ports
infrastru
On Wed, 6 Jun 2012, Doug Barton wrote:
> I purposely have a tiny /tmp, and while building gcc46 today it
> filled up with "stuff" from the gcc build. Is there any way to
> modify this process so that it keeps everything in WRKDIR?
GCC in general should put all its build stuff in WRKDIR and only
st
On Wed, 16 May 2012, Andriy Gapon wrote:
>>> +CFLAGS+= ${CFLAGS.${CC}}
>>> +CXXFLAGS+= ${CXXFLAGS.${CC}}
>>
>> Similarly here. Where does this come from, why is it related to
>> the WITH_GCC versus USE_GCC patch? Can and should this be split
>> out? How is it used and where?
Hi Andriy,
Mark Linimon worked on a similar patchset in the past. Have the
two of you synced and shared patches? I did review some of his
a bit ago, and while I do not have that any more, I believe it
was somewhat different than your approach.
I'll provide some comments below. Note, I am not o
Perhaps I am missing the obvious and will be rewarded with
embarrassement, but where are conventions like the use and
naming of -devel ports described?
I would have expected this to be covered in
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html
but -- it is not.
(If thi
On Mon, 19 Dec 2011, Steve Kargl wrote:
> Not sure why you need confirmation before committing if it works for
> you, because anything has to be better than the current state.
Well, I prefer not having to follow up with further patches later
(and luckily my full testing uncovered another small is
On Mon, 19 Dec 2011, Andriy Gapon wrote:
> The patch worked for me too, thank you.
Thanks, Andriy. I'll commit the patch momentarily, with two updates:
removing patches for ChangeLogs, and fixing an issue with a library
getting named .0.0.so (by pulling in another upstream patch).
> The only sma
On Sat, 17 Dec 2011, b. f. wrote:
> Fixes have already been implemented upstream, at Gerald's request, and
> are in lang/gcc46. But these fixes were introduced after the last
> stable release of gcc 4.6, which corresponds to lang/gcc. When a new
> version of gcc 4.6 is released, and the port is u
On Thu, 15 Dec 2011, Gerald Pfeifer wrote:
>> lang/gcc build would fail for me on FreeBSD 10 (head) with binutils-2.22
>> installed during its configure step with the errors like the following in
>> config.log:
>
> Yes, I am aware of it. lang/gcc is the slowly moving, con
On Thu, 15 Dec 2011, Andriy Gapon wrote:
> lang/gcc build would fail for me on FreeBSD 10 (head) with binutils-2.22
> installed during its configure step with the errors like the following in
> config.log:
Yes, I am aware of it. lang/gcc is the slowly moving, conservative
option, lang/gcc46 being
On Tue, 13 Dec 2011, Thomas Mueller wrote:
> I wondered why the ports collection used development snapshots of gcc
> rather than stable releases.
All you _should_ need to run anything from the FreeBSD Ports Collection
is either the system compiler (GCC or clang) or lang/gcc all of which
are upda
On Tue, 13 Dec 2011, ajtiM wrote:
> I like to do "
> Mitjaportmaster -o lang/gcc lang/gcc46" but do I need to rebuild all ports
> which I use gcc46, please?
This should not be necessary, just replacing lang/gcc46 by lang/gcc
should work.
(Note: "should". I am very confident it does, but as b.f
On Tue, 13 Dec 2011, Sunpoet Po-Chuan Hsieh wrote:
> We have lang/gcc already. This port is created for perferred gcc
> releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk
> update to allow users build ports with lang/gcc instead of lang/gcc46.
Actually, it's even better. :-) Rep
On Mon, 12 Dec 2011, Kevin Oberman wrote:
> Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does
> not seem like this should be too difficult. Just a matter of the
> right person having the time. Would ports specifying gcc46 need to
> be touched?
Nope. All transparent. USE_GCC=4.6+
On Tue, 13 Sep 2011, Lev Serebryakov wrote:
> Or, maybe automate this, as now port system warns user about "possible
> network servers" -- check all installed binaries and libraries for
> linkage with non-system-gcc libraries and add "run" dependency. But
> I'm not sure it is easy to do, as it sh
On Sun, 22 May 2011, Doug Barton wrote:
> Will @unexec in pkg-plist do the job?
On Mon, 23 May 2011, Wesley Shields wrote:
> Are these what you are looking for:
>
> http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
> http://www.freebsd.org/doc/en/books/porters-handbook/pkg-dei
On Mon, 25 Jul 2011, Matthias Andree wrote:
> Namely: if a port sets USE_GCC=4.2+ (for instance, sysutils/busybox does
> that), the Pointyhat build does not install GCC. I think the bug is in
> ports/Mk/bsd.gcc.mk which is unaware that there are newer clang-based
> 9-CURRENT systems without gcc.
>
Trying to implement the final steps in addressing PR 155568: "bsd.gcc.mk:
Fixing dependency not to pick ccache stubs" which I have been working on
with Emanuel, I'd like to invoke a script after a port/package has been
installed and again after it has been deinstalled.
The naive approach below wo
On Fri, 31 Dec 2010, Troy wrote:
> I was trying to upgrade the gcc port and received the following:
>
> portupgrade gcc-4.4.6.20101012
> ** Port marked as IGNORE: lang/gcc44:
> is marked as broken: does not build
> ** Listing the failed packages (-:ignored / *:skipped / !:failed)
>
Addendum: I believe doing this with a specific port for amd64, at least
initially is a good idea, and making this a slave port of emulators/wine
so that things like constantly changing pkg-plist and general updates
come for free. I am also happy to make adjustments to that port, as long
as the "
On Mon, 10 May 2010, Tsurutani Naoki wrote:
>> I just had an idea -- how about the patch below to allow pdftk to build
>> also in a LANG=ja_JP.eucJP setting?
> It works fine on my host !
> Thank you !!
Excellent, thank you for the confirmation!
Greg, do you approve? (This addresses fifty percen
1 - 100 of 154 matches
Mail list logo
