Re: CFD: status of Ada-related ports (including ports-mgmt/synth)

[ 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

Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang

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.

Re: Massive PORTS_REVISION bump after making gcc-9.1 default

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,

Re: Massive PORTS_REVISION bump after making gcc-9.1 default

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

How to best check a configuration of another port/package?

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

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

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

libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

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, > >

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

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

Re: FAudio port required for next version of Wine

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

FAudio port required for next version of Wine

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

Re: USE_GCC usage

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

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

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

Re: It looks like USE_GCC=any is broken and leads to system-clang use

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

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

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

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

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

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

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,

Re: Which wine do I need?

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 ;-).

Re: Which wine do I need?

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 <ger...@freebsd.org> __

Re: INSTALL_TARGET=install-strip runs into "permission denied"

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,

Re: INSTALL_TARGET=install-strip runs into "permission denied"

[ 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

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

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

Re: bsd.sites.mk: Do we prefer http or https (or both)

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

bsd.sites.mk: Do we prefer http or https (or both)

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 ___

Re: svn commit: r432796 - in head/graphics: rawtherapee rawtherapee-devel

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

Re: "Failed: fetch" for emulators/wine-staging

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: >>

Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

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.

Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

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

Re: Needing help getting cad/kicad-devel compiled under FreeBSD-9

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

Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

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

Re: lang/gcc6 (as of /usr/ports -r416711) does not build on 11.0 -r301815 on an rpi2 [armv7-a, cortex-a7]: a.out uses VFP register arguments, . . . does not

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 --

gfortran (was: Any chances to reduce number of gcc ports/packages which are installed as BINARY PACKAGES dependencies?)

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

Re: lang/gcc48 fails to build

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

Re: [package - head-i386-default][emulators/wine-compholio] Failed for wine-compholio-1.7.40,1 in build

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=24430p=99442 Interestingly it only happens on FreeBSD head, though; all other version appear fine. Gerald

Re: [package - head-i386-default][emulators/wine-compholio] Failed for wine-compholio-1.7.40,1 in build

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:

INSTALL_TARGET=install-strip runs into permission denied

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

Re: INSTALL_TARGET=install-strip runs into permission denied

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

Re: Can't build lang/gcc port on i386: segmentation fault

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

Re: Can't build lang/gcc port on i386: segmentation fault

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 BOOTSTRAP.

Re: Any chances to reduce number of gcc ports/packages which are installed as BINARY PACKAGES dependencies?

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 hope

Re: Error: Orphaned: @unexec rmdir /home /dev/null 21 || : (PING)

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 tests. Thinking a bit more about this: Doesn't

Re: Error: Orphaned: @unexec rmdir /home /dev/null 21 || : (PING)

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.

Re: Error: Orphaned: @unexec rmdir /home /dev/null 21 || : (PING)

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 try

Error: Orphaned: @unexec rmdir /home /dev/null 21 || : (PING)

[ 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.

Error: Orphaned: @unexec rmdir /home /dev/null 21 || :

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)

Who broke staging as user?

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 file

Re: Who broke staging as user?

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 things in my

Re: gcc update breakage

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-0.13.2_2

Re: USE_GCC doesn't set rpath

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

Re: FreeBSD 10.0-RC5 AMD64 pkg upgrade fail by gcc/gcc46

with the CONFLICTS, please advise so that we can tighten them. Gerald -- Gerald Pfeifer ger...@pfeifer.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports

Re: FreeBSD 10.0-RC5 AMD64 pkg upgrade fail by gcc/gcc46

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

Re: FreeBSD 10.0-RC5 AMD64 pkg upgrade fail by gcc/gcc46

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

Re: Why can't lang/gcc4X compilers build kernel modules?

On Fri, 10 May 2013, Dimitry Andric wrote: On May 10, 2013, at 18:59, Mikhail T. mi+t...@aldan.algebra.com 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

Re: problem with clamav

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=dateview=log clamav now builds. Thanks for the confirmation. And sorry for the temporary breakage. Gerald

Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)

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

Re: [QAT] r334619: 1x leftovers, 3x success

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. Reported

Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)

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 this,

Re: [QAT] r333268: 4x leftovers

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 following,

Re: [QAT] r333268: 4x leftovers

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.

Re: [QAT] r333268: 4x leftovers

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

Staging and INFO (was: [QAT] r331172: 3x leftovers, 1x install_error)

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

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

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 switch

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

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 portmaster

Re: regression: lang/gcc47, gcc48 on amd64: configure: error: cannot compute suffix of object files: cannot compile

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 and

Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

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/gcc46

Re: Breaking out gcc-ecj45 from lang/gcc{,46,47,48}

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

Breaking out gcc-ecj45 from lang/gcc{,46,47,48}

=== --- gcc-ecj45/Makefile (revision 0) +++ gcc-ecj45/Makefile (working copy) @@ -0,0 +1,22 @@ +# Created by: Gerald Pfeifer ger...@freebsd.org +# $FreeBSD$ + +PORTNAME= gcc-ecj +PORTVERSION= 4.5 +CATEGORIES=lang java +MASTER_SITES= ${MASTER_SITE_SOURCEWARE

Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)

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

Re: lang/gcc46

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

Re: bsd.gcc.mk: USE_FORTRAN.

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 can

Re: lang/gcc46

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 need

Re: lang/gcc46 building stuff in $TMPDIR

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, could

Re: lang/gcc46 building stuff in $TMPDIR

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 lot of

Re: lang/gcc rumdependencies?

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, if

Re: lang/gcc46

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 ports

Re: firefox 13.0,1 needs lang/gcc46 -- to RUN?!

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

Re: WITH_GCC

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? Where is it

Re: WITH_GCC

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

Where are conventions like -devel ports documented?

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

Re: lang/gcc on freebsd 10

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

Re: [PATCH] lang/gcc -- Fix build on freebsd-current

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

Re: lang/gcc on freebsd 10

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, conservative option, lang/gcc46

Re: [PATCH] lang/gcc -- Fix build on freebsd-current

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

Re: lang/gcc on freebsd 10

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

Re: lang/gcc46

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+ or

Re: lang/gcc46

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. :-)

Re: lang/gcc46

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.

Re: lang/gcc46

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

Re: USE_GCC and unnesessary RUN_DENEDS on gcc port (Was: Print +REQUIRED_BY as tree?)

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 should be

Re: [ANNOUNCE]: clang compiling ports, take 2

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. I

How to best run a script post installation _and_ deinstallation?

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

Re: gcc-4.4.6.20101012 marked broken?

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) -

Re: ports/151747: request to enable emulators/wine on amd64

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

Re: CFT: print/pdftk port compiled with Java compiler from gcc 4.5

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 percent of

Re: CFT: print/pdftk port compiled with Java compiler from gcc 4.5

I just had an idea -- how about the patch below to allow pdftk to build also in a LANG=ja_JP.eucJP setting? Does this work? Gerald Index: Makefile === RCS file: /home/ncvs/ports/print/pdftk/Makefile,v retrieving revision 1.30 diff

Re: CFT: print/pdftk port compiled with Java compiler from gcc 4.5

On Tue, 13 Apr 2010, Greg Larkin wrote: Ok, I see why there's a problem now. My linker hints were set up in such a way that /usr/local/lib/gcc45 appeared before /usr/lib, so I didn't have the libstdc++.so.6 problem. However, that's not a normal configuration, so we have to fix this another

Re: CFT: print/pdftk port compiled with Java compiler from gcc 4.5

On Fri, 9 Apr 2010, Gerald Pfeifer wrote: As for the lang/gcc42 issue, I have an idea of how to fix that and will give it try now and share the patch if it works for me. The patch below passes testing for me, and I consider it The Right Thing[TM] directionally, too. The two actual changes

Re: CFT: print/pdftk port compiled with Java compiler from gcc 4.5

On Thu, 8 Apr 2010, Greg Larkin wrote: I maintain the print/pdftk port, and lately it's been getting harder to support compiling it with gcj42 from the lang/gcc42 port. If lang/gcc45 is also installed on the machine, then gcj42 uses the wrong binutils and hilarity ensues. Thanks for pushing

Re: lang/gcc44 Inconsistant package list. Leftover files.

On Sun, 7 Mar 2010, jhell wrote: I still have not resolved the issue or found any leading cause after scrubbing my ports tree completely and grabbing a new copy. Also scrubbed my src.conf make.conf and make.conf.local and ran with and without a jail and can still get those files. So, you

Re: lang/gcc44 Inconsistant package list. Leftover files.

On Fri, 19 Feb 2010, jhell wrote: Below my .sig is what I found upon removal of the old version of gcc44 0126 before re-building 0209. Is there a chance to get this fixed ? Not sure exactly whats causing this so I did not look further into it. Looking at the specific error message, it

Re: bsd.gcc.mk PREFIX or LOCALBASE?

On Mon, 15 Feb 2010, b. f. wrote: Normally, such an rpath directive would automatically be issued, but our lang/gcc4* ports have this default feature disabled unless WITHOUT_JAVA is defined, citing an old PR related to gcj and it's libraries: .if ! defined(WITHOUT_JAVA) ... # FIXME: we

  1   2   >