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

[Gerald Pfeifer]

[ 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 is not covered by Mk/bsd.gcc.mk (aka USE_GCC) any longer. The
port is still in our tree for the time being, though I marked it for
expiration end of February - which gives an extra day this year. ;-)

> I would like to, if possible, eliminate gcc6, as it merely adds 
> build time on the package builders.

Is this a concern for all architectures, or mostly non-x86?  We
can always restrict ONLY_FOR_ARCHS further for such ports if those
focusing on those architectures are in favor.

[ Editorial note: In the meantime I made such a change for lang/gcc48. ]

> There is a variant of lang/gcc6 called lang/gcc6-aux, which is now only 
> required for the Ada-related ports, including ports-mgmt/synth.  fwiw, 
> that port is only available for aarch64/amd64/i386.
> 
> Is anyone willing to take on the work to upgrade our Ada support to
> some later compiler, so that we can delete lang/gcc6-aux as well?

lang/gcc6-aux/files carries a lot of patches (2500+ lines) that I
don't believe should be FreeBSD-local, but upstreamable/upstreamed.

Also there are some small local patches, some backports, in lang/gcc7 
and later especially, that really matter.  Any FreeBSD port around GCC 
probably would want to use those - which is not the case right now.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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.freebsd.org/bugzilla/show_bug.cgi?id=239266

> It turns out that:
> 
> # ls -laT /usr/ports/devel/freebsd-gcc9/files/
> total 44
> drwxr-xr-x  2 root  wheel512 Dec 25 19:25:26 2019 .
> drwxr-xr-x  3 root  wheel512 Dec 25 19:25:26 2019 ..
> -rw-r--r--  1 root  wheel   4781 Dec 25 19:25:26 2019 
> patch-freebsd-format-extensions
> -rw-r--r--  1 root  wheel   1413 Dec 25 19:25:26 2019 patch-freebsd-libdir
> -rw-r--r--  1 root  wheel588 Dec 25 19:25:26 2019 patch-gcc-configure
> -rw-r--r--  1 root  wheel  16346 Dec 25 19:25:26 2019 patch-gcc-freebsd-mips
> -rw-r--r--  1 root  wheel231 Dec 25 19:25:26 2019 xtoolchain.mk.in
> 
> is missing the patch-clang-vec_step that is in:
> 
> FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/

That is a hack that can be used to work around the issue; I strongly
recommend addressing this in clang properly, though.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Massive PORTS_REVISION bump after making gcc-9.1 default

[Gerald Pfeifer]

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++0x, c++11-lang,
>c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
> plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
> 
> This would appear to me like it did catch a great many ports which are 
> not build with or any anything to do will gcc, though I am not sure. 

These ports may not use GCC on your system, or even the majority of 
systems, but there are systems and situations where they do, and bumping 
PORTREVISION is a global binary decision for each port considered.

> E.g. I thought that USES=compiler:c11 and similar were asking for 
> c11 semantics from whatever compiler was used but

Let's look at your example.  ports/Mk/Uses/compiler.mk has the following
on USES=compiler:c11:

  .if ${_COMPILER_ARGS:Mc11}
  .if !${COMPILER_FEATURES:Mc11}
  .if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc) || 
(${ARCH} != amd64 && ${ARCH} != i386) # clang not always supported on Tier-2
  USE_GCC=yes
  CHOSEN_COMPILER_TYPE=   gcc
  .elif ${COMPILER_TYPE} == gcc

That is, if a user has set a preference for GCC or for non x86/x86-64
platforms, GCC is used.

And if there is one legitimate configuration on the planet where a 
PORTREVISION bump is required, we have to perform it in our repository.

(This is not saying I may not have made a mistake somewhere, but in
general those bumps do appear necessary.)

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Massive PORTS_REVISION bump after making gcc-9.1 default

[Gerald Pfeifer]

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 compiler it was built with before the 
> rebuild

This feels a bit like a deja vu?  Wasn't there a similar issue last 
year, with the update from GCC 7 to GCC 8 (or an earlier one)?

And wasn't one finding back then that there was a bug in the tool 
you used to update/build your ports tree?

I just double checked, and

  r507371 | gerald | 2019-07-26 20:35:21 + (Fr., 26 Juli 2019) | 7 lines

  Update the default version of GCC as pulled in via USE_GCC=yes and a
  myriad of other ways from GCC 8 (8.3 right now) to GCC 9 (9.1 right now).

landed in the tree directly before the PORT_REVISION bump you are
referring to, so lang/gcc9 *should* have been installed first and 
then used to rebuild all those bumped ports.


> Should an install of gcc9 preceded all updates? 

Yes.

> Perhaps a note in UPDATING? I certainly looked there before I started 
> when I saw 226 ports in the list.

UPDATING is described as

  This file documents some of the problems you may encounter when 
  upgrading your ports.  We try our best to minimize these disruptions, 
  but sometimes they are unavoidable.

and the update of the default version of GCC in the ports tree should
not be, nor cause, problems worth documenting there.  For example, most
of the updates to Firefox are not mentioned there, either.

> Should I rebuild the ports that were rebuilt prior to the installation 
> of gcc-9.1?

If you want to have a consistent system, and be in line with what the 
majority of users will have, then yes, I'd recommend that.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 statically)
   IGNORE= GCC requires dynamically linked binutils
   .endif

Now the question is: How to implement something like this practically?

Gerald @FreeBSD.org


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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/gcc9 will then get it as well.

Hope this simplifies things for our users!

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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, 
> 
> 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@!
:
> On Sun, 24 Feb 2019, Tijl Coosemans wrote:
>> GCC_4.3.0 instead of GCC_3.3.0.  The gcc commit that changed this
>> doesn't explain why this was done, but we'll have to make the same
>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
>> part of the ABI).  This isn't a blocker for the patch.
>> 
>> I emailed the patch to gerald on 2017-02-21.  He responded in the usual
>> way that he prefers patches submitted upstream and because I thought the
>> patch would not be accepted upstream he proposed an alternative solution
>> where gcc would always add -rpath on FreeBSD so you didn't have to
>> specify it on the command line.  I responded this wouldn't fix the case
>> where clang was used as a linker (e.g. to combine fortran and c++ code
>> in one program) and that the FAQ on the gcc website said it was a bad
>> idea for other reasons.  I also said upstream might accept my patch if
>> it was a configure option but that the gcc configure scripts are
>> complicated and I didn't know where to add it exactly.  Then silence.
> 
> To move this forward, let me include an updated version of the patch
> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for 
> consideration for our ports collection, initially for lang/gcc8 given 
> that this is the default in the ports collection.
> 
> 
> (The lang/gcc* ports actually do carry local patches, e.g. for arm or 
> powerpc or -fuse-ld=lld, but you are right that I usually try to get 
> things upstream first, fixing things upstream myself when I can, or 
> asking for help. The problem in this specific case was/is that I'm 
> quite not enough into this area so cannot really assess and clearly
> stalling over that was not good.)
> 
> 
> Find patch-gfortran-libgcc attached which should simply plug into 
> lang/gcc8/files and lang/gcc8-devel/files.
> 
> Feedback very welcome!
> 
> GeraldGCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
same functions but they also each have their unique functions.  When
gcc links programs and libraries there are three possibilities:

1. gcc -static-libgcc or gcc -static: -lgcc
   => Just use libgcc.a.

2. gcc -shared-libgcc: -lgcc_s -lgcc
   => Link with libgcc_s first, so libgcc.a is only used for its unique
  functions.

3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
   => Link with libgcc.a first so libgcc_s is only used for its unique
  functions (_Unwind_* functions).

Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.

This patch make 3 the default for gfortran.  It significantly reduces
the use of libgcc_s.  The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran.  Consider a dependency tree like this:

  prog -> libA -> libgcc_s (old base system libgcc_s is fine)
   -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang.  Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB.  With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.

Upstream is unlikely accept a patch like this because libgfortran calls
some _Unwind_* functions and so always needs libgcc_s.  Also because
every Fortran program and library links to libgfortran it makes sense
that option 2 above is the default.  On FreeBSD where clang and GCC
compiled code can be mixed and where multiple libgcc_s may be installed,
option 3 is just a lot easier to deal with.

The bug that sparked this is PR 208120 (but note there's a lot of
misleading information in that bug.  CMake is not actually doing
anything wrong.)

--- UTC
--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
}
 }
 
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
   if (library)
 {
   uns

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

[Gerald Pfeifer]

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 including 
some of you was not what I'd like to experience myself as a contributor 
and user, nor what I want to provide to others.

There were some personal reasons, not related to Tijl or FreeBSD at all, 
but that does not change a thing about those experiences, and I am truely 
sorry for those and will work hard to avoid such a case in the future.

On Sun, 24 Feb 2019, Tijl Coosemans wrote:
> GCC_4.3.0 instead of GCC_3.3.0.  The gcc commit that changed this
> doesn't explain why this was done, but we'll have to make the same
> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
> part of the ABI).  This isn't a blocker for the patch.
> 
> I emailed the patch to gerald on 2017-02-21.  He responded in the usual
> way that he prefers patches submitted upstream and because I thought the
> patch would not be accepted upstream he proposed an alternative solution
> where gcc would always add -rpath on FreeBSD so you didn't have to
> specify it on the command line.  I responded this wouldn't fix the case
> where clang was used as a linker (e.g. to combine fortran and c++ code
> in one program) and that the FAQ on the gcc website said it was a bad
> idea for other reasons.  I also said upstream might accept my patch if
> it was a configure option but that the gcc configure scripts are
> complicated and I didn't know where to add it exactly.  Then silence.

To move this forward, let me include an updated version of the patch
Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for 
consideration for our ports collection, initially for lang/gcc8 given 
that this is the default in the ports collection.


(The lang/gcc* ports actually do carry local patches, e.g. for arm or 
powerpc or -fuse-ld=lld, but you are right that I usually try to get 
things upstream first, fixing things upstream myself when I can, or 
asking for help. The problem in this specific case was/is that I'm 
quite not enough into this area so cannot really assess and clearly
stalling over that was not good.)


Find patch-gfortran-libgcc attached which should simply plug into 
lang/gcc8/files and lang/gcc8-devel/files.

Feedback very welcome!

GeraldGCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
same functions but they also each have their unique functions.  When
gcc links programs and libraries there are three possibilities:

1. gcc -static-libgcc or gcc -static: -lgcc
   => Just use libgcc.a.

2. gcc -shared-libgcc: -lgcc_s -lgcc
   => Link with libgcc_s first, so libgcc.a is only used for its unique
  functions.

3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
   => Link with libgcc.a first so libgcc_s is only used for its unique
  functions (_Unwind_* functions).

Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.

This patch make 3 the default for gfortran.  It significantly reduces
the use of libgcc_s.  The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran.  Consider a dependency tree like this:

  prog -> libA -> libgcc_s (old base system libgcc_s is fine)
   -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang.  Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB.  With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.

Upstream is unlikely accept a patch like this because libgfortran calls
some _Unwind_* functions and so always needs libgcc_s.  Also because
every Fortran program and library links to libgfortran it makes sense
that option 2 above is the default.  On FreeBSD where clang and GCC
compiled code can be mixed and where multiple libgcc_s may be installed,
option 3 is just a lot easier to deal with.

The bug that sparked this is PR 208120 (but note there's a lot of
misleading information in that bug.  CMake is not actually doing
anything wrong.)

--- UTC
--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
}
 }
 
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
   if (library)
 {
   unsigned int i;

--- libgfortran/Makefile.in.orig2019-02-22 14:22:13.0 +

Re: FAudio port required for next version of Wine

[Gerald Pfeifer]

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 unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FAudio port required for next version of Wine

[Gerald Pfeifer]

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 available 
though the default is recommended for general use.

https://www.winehq.org/pipermail/wine-devel/2019-February/140206.html

I've been advised that packaging FAudio should be similar to 
openal-soft and work well on 64- as well as 32-bit systems.


Can one of you please help and package/maintain this, please?

Thanks,
Gerald


PS: I have not been using FreeBSD on a desktop for some 15 years and 
zero expertise around sound, plus lack time, so really need help.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC usage

[Gerald Pfeifer]

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 dependency
> Error: /usr/local/bin/ann_in is linked to 
> /usr/local/lib/gcc5/libquadmath.so.0 from lang/gcc but it is not declared as 
> a dependency
> Error: /usr/local/bin/c81merge is linked to 
> /usr/local/lib/gcc5/libstdc++.so.6 from lang/gcc but it is not declared as a 
> dependency
> Error: /usr/local/bin/c81merge is linked to /usr/local/lib/gcc5/libgcc_s.so.1 
> from lang/gcc but it is not declared as a dependency
> 
> Should this be considered a false positive? or should USE_GCC
> also add a LIB_DEPEND to ports?

Thanks for reporting this, Richard.  I missed this back in June,
but a friendly soul pointed me towards this.

USE_GCC currently implies BUILD_DEPENDS (since GCC is used to build
such a port) and RUN_DEPENDS, where I am now thinking we should have
LIB_DEPENDS instead of RUN_DEPENDS, actually. 

And Mathieu Arnold responded:
> This is quite strange. lang/gcc does not provide any of those libraries.
> lang/gcc is a metapackage, the only thing it does is depend on the
> lang/gccXX you asked for, and it provide symlinks:
>
> # pkg info -l lang/gcc
> gcc-5.4.0_2:
>/usr/local/bin/g++
>/usr/local/bin/gcc
> /usr/local/bin/gfortran
> # ls -l $(pkg info -ql lang/gcc)
> lrwxr-xr-x  1 root  wheel  4 29 mai   15:21 /usr/local/bin/g++@ -> g++5
> lrwxr-xr-x  1 root  wheel  4 29 mai   15:21 /usr/local/bin/gcc@ -> gcc5
> lrwxr-xr-x  1 root  wheel  9 29 mai   15:21 /usr/local/bin/gfortran@ -> 
> gfortran5

Is it possible the reporter(s) had an older ports tree, predating
r441883 from 2017-05-27 which adjusted lang/gcc to appear like you
reported?

What do you think about replacing RUN_DEPENDS by LIB_DEPENDS via
the patch below?

My only challenge is that I don't know what to put in instead of
... there given that different lang/gcc* ports do carry the same
libraries (and usually with the same .so version).?

Gerald

Index: bsd.gcc.mk
===
--- bsd.gcc.mk  (revision 450347)
+++ bsd.gcc.mk  (working copy)
@@ -167,7 +167,7 @@
 
 .if defined(_GCC_PORT_DEPENDS)
 BUILD_DEPENDS+=${_GCC_PORT_DEPENDS}:lang/${_GCC_PORT}
-RUN_DEPENDS+=  ${_GCC_PORT_DEPENDS}:lang/${_GCC_PORT}
+LIB_DEPENDS+=  ...:lang/${_GCC_PORT}
 # Later GCC ports already depend on binutils; make sure whatever we
 # build leverages this as well.
 USE_BINUTILS=  yes
@@ -199,5 +199,5 @@
@echo CC=${CC} - CXX=${CXX} - CPP=${CPP} - CFLAGS=\"${CFLAGS}\"
@echo LDFLAGS=\"${LDFLAGS}\"
@echo "BUILD_DEPENDS=${BUILD_DEPENDS}"
-   @echo "RUN_DEPENDS=${RUN_DEPENDS}"
+   @echo "LIB_DEPENDS=${LIB_DEPENDS}"
 .endif
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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

For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux 
ports which I do not maintain) I have now removed packaging the headers
processed by fixincludes, so any problems in that direction should be
gone.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 is out of spec.

(I have had lang/gcc7 essentially ready for weeks, alas on a system that is a 
dead brick due to loss of its power brick and me traveling. Should be finally 
addressed by the end of this week.)

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 misunderstood your previous mail. No worries, I'll gently 
proceed then.

I expect to update gcc5 in the next 24 hours.

>[In my normal/head environment I'm switching to lang/gcc7-devel
>for gcc (from lang/gcc6 ) but I'm odd that way.]

The compiler should be fine, it's a number of ports that are not (even blocking 
the move from GCC 5 to 6 as default).

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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.

>It looks like the the lang/gcc5-devel build still creates and
>uses the headers that go in include-fixed/ but that they are
>removed from $(STAGEDIR}${TARGLIB} 's tree before installation
>or packaging.
>
>So, if I understand right, lang/gcc5-devel itself still does use
>the adjusted headers to produce its own materials but when
>lang/gcc5-devel is used later it does not. Definitely
>something to be testing since it is a mix overall.

I am not worried about that since that should not cause any binary 
incompatibilities (ABI). The problem we encountered was about source code and 
API in a wide sense of that term.

>Is some form of exp-like run needed that tries to force use
>of a release/11.0.1 built lang/gcc5-devel (-r444563) to build
>other things under, say, stable/11  or some draft of
>release/11.1.0 ? Is this odd combination even possible
>currently?

I am not aware of it, and while originally I was thinking to request an -exp 
run (after the GCC version update which is dragging due to broken ports), time 
is not on our side and the change should be low risk.

> [altermative approach] But I guess that did not work out.

Not with my current level of connectivity and my notebook a dead brick on top 
of that. And my preference is to still build, but stow away (unless explicitly 
requested to keep).

>Eventually most of the lang/gcc* 's will need whatever
>technique is used.

Yes, agreed. Version 5 is most important since it's the default; then 6; 4.x is 
for retro computing fans ;-), so 7 will then be next.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 STABLE (and hence hoped we'd have more time for this change).

My Internet connectivity right now is only slightly above pigeon speed, so 
sorry for any delays.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Which wine do I need?

[Gerald Pfeifer]

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

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Which wine do I need?

[Gerald Pfeifer]

On Mon, 15 May 2017, David Naylor wrote:
>> I see several different wine ports and would like to know which I need for
>> amd64 and which I need for an i386 installation.
>  - On an i386 environment with 32-bit Windows binaries use lang/wine.
>  - On an amd64 environment with 32-bit Windows binaries use lang/i386-wine.
>  - On an amd64 environment with 64-bit Windows binaries use lang/wine.

What do you guys think about the following patch for emulators/wine
to help clarify this?

Gerald

Index: pkg-descr
===
--- pkg-descr   (revision 441876)
+++ pkg-descr   (working copy)
@@ -5,8 +5,12 @@
 a similar look and feel to other applications on your desktop.
 
 Many applications already work, more or less, including versions of
-Microsoft Office and several games.
+Microsoft Office and many games.
 
+Use 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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, bsd.port.mk
> could also extract debug symbols into separate files and put them into a
> debug subpackage.

Yes, that sounds a lot more reliable and maintainable (and overall
less work compared to patching hundreds of ports).

Until something like this is in place, should we ignore those
complaints from the QA framework or patch individual ports?

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

[ 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-freebsd10.1/5.0.0/install-tools/fixincl
 strip: unable to copy file 
 '.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
  reason: Permission denied
 Makefile:191: recipe for target 'install-strip' failed
 gmake[3]: *** [install-strip] Error 1
>>> This strip command seems redundant.  Isn't fixincl already stripped by
>>> the "install -s" command above?
>> Good point.
>> 
>>> What does this piece of the log look like outside the ports framework?
>> 
>> /usr/bin/install -c fixinc.sh 
>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixinc.sh
>> /usr/bin/install -c fixincl 
>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
>> /usr/bin/install -c mkheaders 
>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/mkheaders
>> test -z 'strip' || strip 
>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
>> gmake[2]: Leaving directory '.../OBJ-0118-1528/fixincludes'
>> 
>> (I also tried setting STRIP_CMD to true, alas that is not used by GCC.)
> Try adding BINMODE=755 to the port Makefile or STRIP=true to CONFIGURE_ARGS

Both of these allow the build to succeed as a regular user (non-root), 
when INSTALL_TARGET=install-strip is set.

Alas with STRIP=true many files end up being not stripped, whereas with 
the BINMODE setting the list is down to one file.
  
This appears to be the case since various aspects of GCC do not use our
install-* tools, but a script install-sh (which you can find at the root 
of the GCC source tree that uses cp, chmod, strip,... for compatibility 
reasons with many systems).

So I guess setting BINMODE=755 is the best option if we want binaries
and libraries in the gcc* ports stripped?


(This is now also tracked in https://reviews.freebsd.org/D10357 where
miwi proposed a patch originally.)

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 compiler tends to take snapshots
> of the system headers when it is built. cdefs.h is used by all the
> system headers so changes in cdefs.h have good chances affecting
> such builds but any change are likely to cause similar trouble.
> 
> In the case of gcc-aux, it appears the compilation is based on a
> bootstrap compiler which already carries outdated headers.
> A workaround, suggested by gerald@ the last time a similar issue
> happened was to run for install-tools/fixinc.sh. I think that may
> regenerate the headers and let the build use updated headers.
> Ultimately gcc-aux needs maintainer intervention and using
> outdated headers will break sooner or later: especially on -current.

Indeed, thanks for the analysis/background, Pedro!

I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, 
and perhaps John (as the maintainer of that port) has plans to update 
it?  Let me copy him.

Gerald

PS: John, if you have an update, happy to help and apply that for you.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 both.
 
Another question on "https first", Tijl.  Some MASTER_SITEs
have a dozen entries or more, and I always thought that the
infrastructure picks one of these randomly every time.  In
some tests I did today with two sites (one https, one http)
it _always_ picked the first, confirming your point.  Or is
that only the case for `make makesum`?

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 ("FreeBSD").

Would it make sense to add a check to portlint that every condition
(or practically probably line, considering "...\\\n..." as one line)
that has OSVERSION also has OPSYS?

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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:
>> ===>  License LGPL21 LGPL3 accepted by the user
>> ===>   wine-staging-2.0.r4_1,1 depends on file: /usr/local/sbin/pkg - found
>> => wine-2.0-rc4.tar.bz2 doesn't seem to exist in 
>> /net/grundoon/mnt/tank/ports/distfiles/.
>> => Attempting to fetch 
>> http://downloads.sourceforge.net/project/wine/Source/wine-2.0-rc4.tar.bz2
>> wine-2.0-rc4.tar.bz2  100% of   22 MB  617 kBps 
>> 00m37s
>> => v2.0-rc4.tar.gz is not in 
>> /net/grundoon/mnt/tank/ports/emulators/wine-staging/../wine-devel/distinfo.
>> => Either 
>> /net/grundoon/mnt/tank/ports/emulators/wine-staging/../wine-devel/distinfo 
>> is out of date, or
>> => v2.0-rc4.tar.gz is spelled incorrectly.
>> *** Error code 1

This happened since wine-staging is a slave port of wine-devel, alas 
the availability of the Wine Staging patchset tends to trail the one 
of Wine itself by a few days.

This time I had simply missed this and hence, while wine-devel
tested just fine before my commit, wine-staging broke as you noticed.

(This is a little annoying since I need to artificially delay updates
of the wine-devel port until that extra patchset is ready, for the
wine-staging port and if someone sets the STAGING option in the main
port.)

> Gerald, please see above. In r430845, the info for the wine-staging 
> tarball disappeared from wine-devel/distinfo.

Thanks for the hint!

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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_GCC=any is the equivalent of USE_GCC=4.2+, and lang/gcc6 and
lang/gcc6-devel should both meet this requirement.

(In general, do not use a gcc*-devel port unless you really want 
or need to, though; use the corresponding gcc* port instead.)

> Additional information (gained later) is that if I "pkg delete 
> gcc6-devel" then instead of devel/kBuild trying to install lang/gcc6 
> it tries to install lang/gcc (no number).

That works as designed.  USE_GCC=yes defaults to lang/gcc.  USE_GCC=any 
tries to use an existing GCC system compiler and lang/gcc by default if 
none is present.

> If I clean that out and put back lang/gcc6-devel and try again it 
> goes back to trying to install lang/gcc6 .

That is a little odd.  It means gcc6 from lang/gcc6-devel is found
and identified as a suitable version of GCC.

Then Mk/bsd.gcc.mk adds

  BUILD_DEPENDS+= gcc6:lang/gcc6

when it resolves USE_GCC=any.

That should not trigger and pull in lang/gcc6, though, as long
as gcc6 is found.

> It appears to be picking up that a gcc is installed when
> lang/gcc6-devel and that it is is version 6 based but then
> it looks for lang/gcc6 specifically but does not find it
> and so tries to install lang/gcc6. Its identification of the
> version is not enough to identify what specific gcc port
> to look for but it only looks for the one possible source
> to satisfy the dependency --and not finding that specific
> port it then tries to install that specific port that it
> did not find.

That's pretty close.  It finds the gcc6 binary and hence settles
on GCC 6 as the compiler to use, but when resolving dependencies
then it apparently does not find the gcc6 binary (or does, and
something triggers a full rebuild regardless with lang/gcc6 instead 
of the original lang/gcc6-devel).


Do you, by any chance, have some non-standard settings that would
trigger such an unconditional rebuild?


In general, for ports work lang/gcc is the one to use, and lang/gccX 
over lang/gccX-devel.

Somehow it feels your setup adds layers of shaky, untested and
non-standard elements on top of each other.


As far as lang/gcc* ports are concerned, I believe the best use
of our time will be moving lang/gcc from GCC 4.9 (where it finally
got to) to GCC 5.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 they provide.

> After installing lang/gcc6-devel something else indirectly
> forced lang/gcc6 to try to build. The attempt failed with:

That means that "something else indirectly forc[ing] lang/gcc6" is
what appears to be going on here.  I double checked Mk/bsd.gcc.mk
and failed to find anything (which also would be surprising given
no other reports in the last decade).

vbox@, any ideas?

Gerald

> The specific example turns out to be. . .
> 
> emulators/virtualbox-ose-additions leads to:
> 
> ===>>> The following actions will be taken if you choose to proceed:
> Upgrade virtualbox-ose-additions-5.1.8 to 
> virtualbox-ose-additions-5.1.10
> Install devel/kBuild
> Install lang/gcc6
> Install textproc/flex
> 
> and lang/gcc6 tries to build during devel/kBuild and the 3
> non-lang/gcc6 items above have:
> 
> # grep -i gcc emulators/virtualbox-ose-additions/Makefile 
> devel/kBuild/Makefile textproc/flex/Makefile 
> emulators/virtualbox-ose-additions/Makefile:CONFIGURE_ARGS+=--nofatal 
> --with-gcc="${CC}" --with-g++="${CXX}"
> emulators/virtualbox-ose-additions/Makefile:@${ECHO} 'VBOX_GCC_std = 
> -std=c++11' >> ${WRKSRC}/LocalConfig.kmk
> emulators/virtualbox-ose-additions/Makefile:@${ECHO} 
> 'VBOX_GCC_Wno-unused-parameter = -Wno-unused-parameter' >> \
> devel/kBuild/Makefile:USE_GCC=  any
> devel/kBuild/Makefile:  ${REINPLACE_CMD} -e 's|gcc|${CC}|g' $$f ; \
> 
> In a context with:
> 
> # pkg info | grep -i gcc
> gcc6-devel-6.2.1.s20161201 GNU Compiler Collection 6
> powerpc64-gcc-6.2.0Cross GNU Compiler Collection for powerpc64
> powerpc64-xtoolchain-gcc-0.1   Pre seeded toolchain to cross build FreeBSD 
> base
> 
> # more /etc/make.conf 
> WANT_QT_VERBOSE_CONFIGURE=1
> #
> DEFAULT_VERSIONS+=perl5=5.24
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES=
> MALLOC_PRODUCTION=
> 
> 
> So apparently lang/gcc6-devel can not substitute for lang/gcc6
> automatically.
> 
> 
> 
> Now that devel/powerpc64-gcc is 6.2.0 based it and lang/gcc6 may also
> conflict (I do not know yet: build in progress).
> 
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 territory where, based on input 
from Tijl and others, we now distinguish between lang/gcc5 and 
lang/gcc5-devel.)

> But luckily so far I've not picked to build anything that built
> lang/gcc. Or, more likely(?), if some gcc is already installed it
> is used instead if lang/gcc is not installed yet.

Correct.  If lang/gcc49 or lang/gcc is installed, either of the
two is picked up; if a newer version is installed and USE_GCC=yes
or USE_GCC=X.Y+ are requested (and the installed version is newer),
that one is used.

Nothing to do with luck on your side, Mark.  Rather, design and 
implementation in the Ports Collection. :-)

Gerald

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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  should be imported in
> in namespace std::tr1. */
> /* #undef _GLIBCXX_USE_C99_MATH_TR1 */

I verified that current versions of GCC on FreeBSD 10.3 have
this on...

> It looks like this file is generated at build time, so something in
> gcc's configure scripts is turning off the "C99_MATH_TR1" support.

...I believe since FreeBSD 10 has better libc support for the long 
math functions, so our best course of action (apart from counting 
down those months that FreeBSD 9 still has) is seeing that we can 
finally update lang/gcc from GCC 4.8 to at least 4.9, if not later.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 our lang/gcc* ports).

If there is anything you see missing, please advise.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 -- or a local patch
like this).

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 port, now features
gfortran as well as gcc and g++ without the appended major version 
number.

(Not committed yet; feedback very welcome.)

Gerald

Index: Makefile
===
--- Makefile(revision 402204)
+++ Makefile(working copy)
@@ -3,6 +3,7 @@
 
 PORTNAME=  gcc
 PORTVERSION=   4.8.5
+PORTREVISION=  1
 CATEGORIES=lang java
 MASTER_SITES=  GCC/releases/gcc-${DISTVERSION}
 
@@ -158,5 +159,10 @@
fi
 .endfor
cd ${WRKDIR} ; ${SED} -i -e "/PLIST.lib/ r PLIST.lib" ${TMPPLIST}
+   # This is the canonical GCC port, so add key commands without
+   # version numbers as part of their names.
+   for c in gfortran g++ gcc; do \
+   ${LN} -s ${PREFIX}/bin/$$c${SUFFIX} ${STAGEDIR}${PREFIX}/bin/$$c; \
+   done
 
 .include 
Index: pkg-plist
===
--- pkg-plist   (revision 402204)
+++ pkg-plist   (working copy)
@@ -8,12 +8,15 @@
 bin/%%GNU_HOST%%-gfortran%%SUFFIX%%
 bin/c++%%SUFFIX%%
 bin/cpp%%SUFFIX%%
+bin/g++
 bin/g++%%SUFFIX%%
+bin/gcc
 bin/gcc%%SUFFIX%%
 bin/gcc-ar%%SUFFIX%%
 bin/gcc-nm%%SUFFIX%%
 bin/gcc-ranlib%%SUFFIX%%
 bin/gcov%%SUFFIX%%
+bin/gfortran
 bin/gfortran%%SUFFIX%%
 @comment info/gcc%%SUFFIX%%/dir
 man/man1/cpp%%SUFFIX%%.1.gz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc48 fails to build

[Gerald Pfeifer]

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 lang/gcc port just last night (which is pretty much the same)
and did not run into this.

> Is this a known error? It seems, there is something odd with C++ mode 
> and C files?

GCC now is built as C++ code, even though most source files have
not been renamed from .c.  So this warning is expected and can be
ignored.

This being an old port, nothing has changed on the GCC side.  Which
means something in -CURRENT must have broken it.

Gerald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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:  
> http://beefy3.isc.freebsd.org/build.html?mastername=head-i386-default&build=p383446_s281156
> Log:
> 
> >> Building emulators/wine-compholio
> build started at Tue Apr  7 04:55:12 UTC 2015
> port directory: /usr/ports/emulators/wine-compholio
> building for: FreeBSD head-i386-default-job-13 11.0-CURRENT FreeBSD 
> 11.0-CURRENT #0 r279966: Fri Mar 13 22:02:53 UTC 2015 
> pe...@build-11.freebsd.org:/usr/obj/usr/src/sys/CLUSTER11  i386
> maintained by: ger...@freebsd.org
> Makefile ident:  $FreeBSD: head/emulators/wine-compholio/Makefile 375756 
> 2014-12-28 20:39:48Z dbn $
> Poudriere version: 3.1.3
> Host OSVERSION: 1100064
> Jail OSVERSION: 1100067
> 
> !!! Jail is newer than host. (Jail: 1100067, Host: 1100064) !!!
> !!! This is not supported. !!!
> !!! Host kernel must be same or newer than jail. !!!
> !!! Expect build failures. !!!

Apart from me wondering why those test results are shared if
build failures are to be expected

> cc -c -o socket.o socket.c -I. -I../../include -D__WINESRC__ -DUSE_WS_PREFIX 
> -D_REENTRANT -fPIC -Wall \
>   -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
> -Wignored-qualifiers \
>   -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith 
> -fno-omit-frame-pointer \
>   -I/usr/local/include -O2 -pipe  -fstack-protector -fno-strict-aliasing
> socket.c:368:27: error: use of undeclared identifier 'WS_IPX_PTYPE'
> DEBUG_SOCKOPT(WS_IPX_PTYPE);
>   ^
> socket.c:330:32: note: expanded from macro 'DEBUG_SOCKOPT'
> #define DEBUG_SOCKOPT(x) case (x): stropt = #x; break
>^
> socket.c:369:27: error: use of undeclared identifier 'WS_IPX_FILTERPTYPE'
> DEBUG_SOCKOPT(WS_IPX_FILTERPTYPE);
>   ^
> socket.c:330:32: note: expanded from macro 'DEBUG_SOCKOPT'
> #define DEBUG_SOCKOPT(x) case (x): stropt = #x; break
>^
> socket.c:370:27: error: use of undeclared identifier 'WS_IPX_DSTYPE'
> DEBUG_SOCKOPT(WS_IPX_DSTYPE);
>   ^

...does anyone know what is going on in HEAD and what to do about
it?

Or is this a temporary thing and we should ignore this on the ports
side?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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.0/install-tools/fixincl
>> 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-freebsd10.1/5.0.0/install-tools/fixincl
>> strip: unable to copy file 
>> '.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
>>  reason: Permission denied
>> Makefile:191: recipe for target 'install-strip' failed
>> gmake[3]: *** [install-strip] Error 1
> This strip command seems redundant.  Isn't fixincl already stripped by
> the "install -s" command above?

Good point.

> What does this piece of the log look like outside the ports framework?

/usr/bin/install -c fixinc.sh 
.../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixinc.sh
/usr/bin/install -c fixincl 
.../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
/usr/bin/install -c mkheaders 
.../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/mkheaders
test -z 'strip' || strip 
.../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
gmake[2]: Leaving directory '.../OBJ-0118-1528/fixincludes'

(I also tried setting STRIP_CMD to true, alas that is not used by GCC.)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INSTALL_TARGET=install-strip runs into "permission denied"

[Gerald Pfeifer]

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 since
install sets binaries to r-x, at which point strip then fails.

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.0/install-tools/fixincl
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-freebsd10.1/5.0.0/install-tools/fixincl
strip: unable to copy file 
'.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
 reason: Permission denied
Makefile:191: recipe for target 'install-strip' failed
gmake[3]: *** [install-strip] Error 1

How do we best go about this?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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.

I am curious, what happens when you try lang/gcc48?

My expectation would be both lang/gcc and lang/gcc48 to behave
the same, since it's a very similar codebase, gcc48 just a bit
newer on the same branch.

We could make BOOTSTRAP the default for lang/gcc, though not 
doing that and thus building a lot faster has been one of the 
features of lang/gcc. -- Since it does not reproduce for me,
do others see the same failure?

Gerald

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 running weekly testers for 
about a year (until I switch that to GCC 4.9 a few months ago),
which has never exhibited that.

Is there anything special on your end (in base, hardware, options...)?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 that at one point we can
eventually get rid of USE_GCC=any.

What I can do for now, and have been planning to do for a few weeks,
is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192025 aka
"Update default version of GCC (USE_GCC=yes, lang/gcc,...) to GCC 4.8".

>  Or build binary packages WITHOUT java by default!? Does anybody uses gcj
>  FOR REAL when we have native openjdk7 and openjdk8?!

There is good news, and there is bad news.  The bad news is that 
print/pdftk actually relies on the Java functionality in the GCC ports 
to build.  The good news is that it seems to be the only such port.

Mathieu, is there a way you can help?  I'd be happy to turn off Java
by default (but leave it in).

On top of these two, the really nice improvement is going to be when
we can support the creation of several packages out of one port -- at
that point we'd just break out a small gcc-runtime package.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || : (PING)

[Gerald Pfeifer]

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 this just silence the 
diagnostics, while "something" still adds those entries to the 
package that trie to remove the parent directories of LOCALBASE?

That is, shouldn't those @unexec rmdir's not be added beyond 
("higher") than LOCALBASE?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || : (PING)

[Gerald Pfeifer]

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 attached patch.

Cool.  That fixes the issue in my tests.

Thank you!

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || : (PING)

[Gerald Pfeifer]

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.
>>   > Checking for pkg-plist issues (check-plist)
>>   ===> Parsing plist
>>   ===> Checking for items in STAGEDIR missing from pkg-plist
>>   Error: Orphaned: @unexec rmdir "/home/gerald" >/dev/null 2>&1 || :
>>   Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || :
>> Any ideas what is going on here?  And what is adding those interesting
>> @unexec rmdir entries?
> You can try to add NO_PREFIX_RMDIR=yes to your port when you test it.
> Testing PREFIX!=LOCALBASE often produces strange results anyway,  in
> most cases people should test PREFIX=LOCALBASE != /usr/local and not
> PREFIX!=LOCALBASE.

Yes, but this had been working without problems for many years. :-) And 
now only problem is this new (pkg-ng?) code and check-plist; apart from 
that things work.

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

Gerald
 

PS: NO_PREFIX_RMDIR=yes makes things worse by adding the last three lines
to the output of check-plist.

Error: Orphaned: @unexec rmdir "/home/gerald" >/dev/null 2>&1 || :
Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || :
Error: Orphaned: @unexec rmdir "/scratch2/tmp/gerald" >/dev/null 2>&1 || :
Error: Orphaned: @unexec rmdir "/scratch2/tmp" >/dev/null 2>&1 || :
Error: Orphaned: @unexec rmdir "/scratch2" >/dev/null 2>&1 || :
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || : (PING)

[Gerald Pfeifer]

[ 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.
  > Checking for pkg-plist issues (check-plist)
  ===> Parsing plist
  ===> Checking for items in STAGEDIR missing from pkg-plist
  Error: Orphaned: @unexec rmdir "/home/gerald" >/dev/null 2>&1 || :
  Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || :

Any ideas what is going on here?  And what is adding those interesting
@unexec rmdir entries?  

Either these should not be added, or check-plist should not error out
when seeing them.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || :

[Gerald Pfeifer]

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)
  ===> Parsing plist
  ===> Checking for items in STAGEDIR missing from pkg-plist
  Error: Orphaned: @unexec rmdir "/home/gerald" >/dev/null 2>&1 || :
  Error: Orphaned: @unexec rmdir "/home" >/dev/null 2>&1 || :

Any ideas what is going on here?  And what is adding those interesting
@unexec rmdir entries?  

Either these should not be added, or check-plist should not error out
when seeing them.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Who broke staging as user?

[Gerald Pfeifer]

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

Are you planning to commit this?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Who broke staging as user?

[Gerald Pfeifer]

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 or directory
  *** Error code 2

After scratching my head, I reran my tests for lang/gcc49 as in the 
tree today, and -- failure as well.

Since I never commit an update to one of these ports without this
kind of testing something must have broken this on June 6th or later.

Digging into svn log $PORTSDIR/Mk a bit, here is my suspect:

  r357076 | antoine | 2014-06-08 21:25:54 + (Sun, 08 Jun 2014) | 8 lines

  Kill NO_LDCONFIG_MTREE, it is long dead
  Make USE_LDCONFIG work when PREFIX!=LOCALBASE,
  LDCONFIG_DIR and LDCONFIG_32DIR are expected in LOCALBASE

  Phabric:D195
  Reviewed by:bapt
  With hat:   portmgr

For my test, LOCALBASE=/home/gerald/10-i386 and 
PREFIX=/scratch2/tmp/gerald/prefix.

But, in general LOCALBASE may not be writeable, whereas PREFIX is,
so I somehow doubt the logic to begin with.

Though the failure here is a lack of ${MKDIR} in the staging directory
somewhere it seems?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: devel/binutils and devel/gnulibiberty version mismatch

[Gerald Pfeifer]

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

As far as libiberty.a goes, I think at least the lang/gcc* ports should
be good.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gcc update breakage

[Gerald Pfeifer]

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
> ===>  Checking if net-p2p/libtorrent already installed
> ===>   libtorrent-0.13.2_2 is already installed
>   You may wish to ``make deinstall'' and install this port again
>   by ``make reinstall'' to upgrade it properly.
>   If you really wish to overwrite the old port of net-p2p/libtorrent
>   without deleting it first, set the variable "FORCE_PKG_REGISTER"
>   in your environment or the "make install" command line.
> *** [check-already-installed] Error code 1
> 
> Stop in /usr/ports/net-p2p/libtorrent.
> *** [install] Error code 1
> 
> I've tried manually deinstalling, reinstalling, cleaning, etc. Any clues?

This looks really weird in net-p2p/rtorrent/Makefile:

   BUILD_DEPENDS= libtorrent=0.13.2_1:${PORTSDIR}/net-p2p/libtorrent
   RUN_DEPENDS= libtorrent=0.13.2_1:${PORTSDIR}/net-p2p/libtorrent

I have never seen such a crazy dependency before.  Try making this
_2 instead of _1, but, really, this is crazy.

Andrej, any idea?

Why is this not checking for libtorrent.so?  And a LIB_DEPENDS instead?
Something like

   LIB_DEPENDS= libtorrent.so:${PORTSDIR}/net-p2p/libtorrent

?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC doesn't set rpath

[Gerald Pfeifer]

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 designed to be backward compatible and have the 
> same so-number for a reason.

Yes!

And in a world hopefully not too far away at one point we'll just
have a gcc-runtime port that comes from the _newest_ stable version 
of GCC in the ports tree and is used by all other versions.

(In my day job, we have been doing this for years.  Once we have
several binary packages from one port, that ought to be relatively
straightforward.)

Gerald

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

Yes, you can only have one of lang/gcc and lang/gcc46 installed (and they are 
basically the same right now until lang/gcc moves to GCC 4.7 soon hopefully).

And the two ports _should_ properly conflict.

I recommend removing gcc46 and everything should be fine.

And if anyone sees a problem with 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-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 difficult, 
>> should it be done?
> 
> In my opinion, this is a fruitless direction.  Neither upstream gcc, nor
> upstream clang will ever accept an option called "-fformat-extensions",
> which enables FreeBSD kernel-specific format extensions (which might
> also change in the future, so you do not really gain anything).
> 
> I think the best solution is to get rid of all non-standard printf
> format specifiers in the kernel, and use custom formatters for our
> specialized needs.  For replacing the %b specifier, for example, we
> could use NetBSD's snprintb() (see
> ).
> 
> Getting rid of non-standard extensions in general is really the way to
> go.  This would enable compiling with any standards-compliant compiler,
> even commercial ones.

Amen.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: problem with clamav

[Gerald Pfeifer]

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
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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, and in my environment it seems to work
(passing the tests described in the Handbook).

ports/184178 when you commit this. :)

Thanks,
Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 ports tree which is not up to date

Good point.  Staring at logs, I was wondering about that.

How about adding the output of `svn info | grep Revision` to the
top of the log file (or something like that)?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 by:  QAT, amdmi3, mandree, bf, dbn
> PR:   184178
> -
> 
>   Build ID:  2013110400-1181
>   Job owner: ger...@freebsd.org
>   Buildtime: 2 hours
>   Enddate:   Sat, 23 Nov 2013 00:19:05 GMT
> 
>   Revision:  r334619
>   Repository:
> https://svnweb.freebsd.org/ports?view=revision&revision=334619
> 
> -
> 
> Port:lang/gcc46 4.6.4_1,1
> 
>   Buildgroup: 8.4-QAT/amd64
>   Buildstatus:   SUCCESS
>   Log: 
> https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230452/gcc-4.6.4_1,1.log
> 
>   Buildgroup: 8.4-QAT/i386
>   Buildstatus:   SUCCESS
>   Log: 
> https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230453/gcc-4.6.4_1,1.log
> 
>   Buildgroup: 9.2-QAT/amd64
>   Buildstatus:   SUCCESS
>   Log: 
> https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230454/gcc-4.6.4_1,1.log
> 
>   Buildgroup: 9.2-QAT/i386
>   Buildstatus:   LEFTOVERS
>   Log: 
> https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230455/gcc-4.6.4_1,1.log
> 
> 
> --
> Buildarchive URL: 
> redports 
> 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 lang/gcc46 port.

This is _not_ an issue with lang/gcc46, but with the general ports
infrastructure that I first reported on October 23rd.

Bapt had a first patch a week ago
  http://people.freebsd.org/~bapt/info-dir.diff

This indeed removed the stray info/ directory, but caused the following
upon `make deinstall` in my testing:

  /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such
  file or directory) and could not create (No such file or directory)
  /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such
  file or directory) and could not create (No such file or directory)
  :


I just committed a workaround to lang/gcc46, will work on lang/gcc next, 
and filed PR ports/184178 to track this on the infrastructure side.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [QAT] r333268: 4x leftovers

[Gerald Pfeifer]

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, which I don't think I've seen
without your patch upon `make deinstall`:

/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)
/scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file 
or directory) and could not create (No such file or directory)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [QAT] r333268: 4x leftovers

[Gerald Pfeifer]

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
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [QAT] r333268: 4x leftovers

[Gerald Pfeifer]

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.

Help welcome!

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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
> 
>   Revision:  r331172
>   Repository:
> https://svnweb.freebsd.org/ports?view=revision&revision=331172
> 
> -
> 
> Port:lang/gcc49 4.9.0.20131020
> 
>   Buildgroup: 8.4-QAT/amd64
>   Buildstatus:   LEFTOVERS
>   Log: 
> https://qat.redports.org//~ger...@freebsd.org/20131021182801-5361-211000/gcc-4.9.0.20131020.log

This is an extra directory usr/local/info/gcc49 left.

Looks like a bug in the staging code to me that should also affect
a number of other ports, not the lang/gcc49 port.

I tried the patch below, alas that didn't do the trick.  Perhaps it 
inspires someone, though?

Gerald


Index: bsd.stage.mk
===
--- bsd.stage.mk(revision 331331)
+++ bsd.stage.mk(working copy)
@@ -70,6 +70,7 @@
>> ${TMPPLIST}
 .else
@${LS} ${STAGEDIR}${PREFIX}/${INFO_PATH}/$i.info* | ${SED} -e 
s:${STAGEDIR}${PREFIX}/:@info\ :g >> ${TMPPLIST}
+   @${ECHO_CMD} "@dirrmtry %D/${INFO_PATH}" >> ${TMPPLIST}
 .endif
 .endfor
 .endif
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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
globally, we'll need more extensive testing, a full ports builds
run, since there is a chance that some port you are not using may
be broken, and I hope to get this done in the coming weeks.

> Also, I saw that gcc48 is released.
> Do you have any plans to make gcc49 port?

I did so yesterday. :-)  It should be in your ports tree with the
next update.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 issue. My
> understanding is that this user want
> 
> When I change GCC_DEFAULT_VERSION to 4.7, it now depends on the gcc47
> package, but still is using lang/gcc:

You're right!

In addition to setting GCC_DEFAULT_VERSION to 4.7, one also needs
to adjust the following in Mk/bsd.gcc.mk:

  .   if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
  _GCC_PORT:= gcc
  .   else
  _GCC_PORT:= gcc${V}
  .   endif

The most correct way of doing this would be replacing the first line by
  .   if ${_USE_GCC} == 4.6
That should then do the right thing; or you could just remove everything
except for
  _GCC_PORT:= gcc${V}
Either should work.


(I'd love to update GCC_DEFAULT_VERSION to 4.7 one of these days; is
the cluster sufficiently recovered for a test run?)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 works on i386, say?

> Shall I open a GCC PR?

No, unless it looks like a general issue.  So far my guess is that
it may be something in your environment.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 via USE_FORTRAN=yes.
> 
> So I wonder if there are any side effects or unexpected
> effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7?

this should work.  In my experience most ports that work with
GCC 4.6 also should with GCC 4.7, and most have USE_GCC=4.6+
anyway, so other users may well have built them with a later
version aleady.

One or the other port may exhibit a compile problem, in which
case that would be an excellent opportunity to file a report
against it and inform its maintainer.

> And anyway, 4.7 will be the default soon, right?

That's what I have been hoping to do, yes.  With the ports
build cluster being unavailable for months now, we simply
could not do the necessary testing though.

Anyone who wants to give this a try, I'd be happy to see that.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 java/eclipse-ecj port?

I should have mentioned that I actually was looking into that option 
first, but (a) build dependencies became really heavy (and build-
time for something like lang/gcc would increase badly), (b) run-time 
dependencies will grow, and (c) this is not what we have been doing
in terms of extensive building and testing, and (d) different from
many others have been doing.

That said, if someone wants to give it a try and test, I'd definitely
be open to make this an OPTION.

Makes sense?

Gerald

PS: ports.svn/java/eclipse-ecj> make build-depends-list
.../gerald/ports.svn/devel/apache-ant
.../gerald/ports.svn/java/openjdk6

ports.svn/java/eclipse-ecj> make run-depends-list
.../gerald/ports.svn/java/openjdk6

ports.svn/java/openjdk6> make build-depends-list
.../gerald/ports.svn/archivers/unzip
.../gerald/ports.svn/archivers/zip
.../gerald/ports.svn/devel/gmake
.../gerald/ports.svn/java/bootstrap-openjdk
.../gerald/ports.svn/print/cups-client
.../gerald/ports.svn/print/freetype2
.../gerald/ports.svn/x11-toolkits/libXt
.../gerald/ports.svn/x11-toolkits/open-motif
.../gerald/ports.svn/x11/libX11
.../gerald/ports.svn/x11/libXext
.../gerald/ports.svn/x11/libXi
.../gerald/ports.svn/x11/libXpm
.../gerald/ports.svn/x11/libXtst

ports.svn/java/openjdk6> make run-depends-list
.../gerald/ports.svn/java/java-zoneinfo
.../gerald/ports.svn/java/javavmwrapper
.../gerald/ports.svn/print/freetype2
.../gerald/ports.svn/x11-fonts/dejavu
.../gerald/ports.svn/x11-toolkits/libXt
.../gerald/ports.svn/x11-toolkits/open-motif
.../gerald/ports.svn/x11/libX11
.../gerald/ports.svn/x11/libXext
.../gerald/ports.svn/x11/libXi
.../gerald/ports.svn/x11/libXpm
.../gerald/ports.svn/x11/libXtst


Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

Hi there,

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.

The patch below shows this, and also -- in case of lang/gcc48 --
how I am planning to adjust the lang/gcc{,46,47,48} ports.


Let me know if you have any comments/suggestions on these changes
which I plan to commit in one, two days.  (The below passed the
official set of ports and package testing.)

Gerald

Index: gcc-ecj45/Makefile
===
--- 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}
+MASTER_SITE_SUBDIR+=   java/
+DISTNAME=  ecj-${PORTVERSION}.jar
+EXTRACT_SUFX=
+EXTRACT_ONLY=
+
+MAINTAINER=ger...@freebsd.org
+COMMENT=   Eclipse Java Compiler used to build GCC Java
+
+NO_BUILD=  yes
+PLIST_FILES=   share/java/${DISTNAME}
+
+do-install:
+   ${INSTALL_DATA} ${DISTDIR}/${DISTNAME} ${PREFIX}/share/java/
+
+.include 
Index: gcc-ecj45/distinfo
===
--- gcc-ecj45/distinfo  (revision 0)
+++ gcc-ecj45/distinfo  (working copy)
@@ -0,0 +1,2 @@
+SHA256 (ecj-4.5.jar) = 
98fd128f1d374d9e42fd9d4836bdd249c6d511ebc6c0df17fbc1b9df96c3d781
+SIZE (ecj-4.5.jar) = 1470676
Index: gcc-ecj45/pkg-descr
===
--- gcc-ecj45/pkg-descr (revision 0)
+++ gcc-ecj45/pkg-descr (working copy)
@@ -0,0 +1,2 @@
+A pre-built version of the Eclipse Java Compiler (ECJ) used to build
+the Java frontend of the GNU Compiler Collection (GCC).


Index: gcc48/Makefile
===
--- gcc48/Makefile  (revision 310417)
+++ gcc48/Makefile  (working copy)
@@ -98,13 +98,12 @@
 .endif
 
 .if ${PORT_OPTIONS:MJAVA}
-ECJ_JAR=   ecj-4.5.jar
-MASTER_SITES+= ${MASTER_SITE_SOURCEWARE:S|$|:ecj|}
-MASTER_SITE_SUBDIR+=   java/:ecj
-DISTFILES+=${ECJ_JAR}:ecj
-EXTRACT_ONLY=  ${DISTFILES:S|${ECJ_JAR}:ecj||}
-BUILD_DEPENDS+=zip:${PORTSDIR}/archivers/zip
+ECJ_JAR=   ${LOCALBASE}/share/java/ecj-4.5.jar
+BUILD_DEPENDS+=${ECJ_JAR}:${PORTSDIR}/lang/gcc-ecj45 \
+   zip:${PORTSDIR}/archivers/zip
+RUN_DEPENDS+=  ${ECJ_JAR}:${PORTSDIR}/lang/gcc-ecj45
 EXTRA_PATCHES+=${FILESDIR}/java-patch-hier
+CONFIGURE_ARGS+=--with-ecj-jar=${ECJ_JAR}
 LANGUAGES:=${LANGUAGES},java
 MAN1+= aot-compile${SUFFIX}.1 \
gappletviewer${SUFFIX}.1 \
@@ -136,10 +135,6 @@
gcc${SUFFIX}/gcj \
gcc${SUFFIX}/libffi
 PLIST_SUB+=JAVA=""
-
-# Prep the source tree for the GCJ build.
-post-patch::
-   @${CP} ${DISTDIR}/${ECJ_JAR} ${SRCDIR}/ecj.jar
 .else
 CONFIGURE_ARGS+=--disable-libgcj
 PLIST_SUB+=JAVA="@comment "
Index: gcc48/distinfo
===
--- gcc48/distinfo  (revision 310417)
+++ gcc48/distinfo  (working copy)
@@ -1,4 +1,2 @@
 SHA256 (gcc-4.8-20130106.tar.bz2) = 
5da1212249d54b907bf515a86e99bcf197123c29fac9d1b6f9955cb157ab7a47
 SIZE (gcc-4.8-20130106.tar.bz2) = 81998118
-SHA256 (ecj-4.5.jar) = 
98fd128f1d374d9e42fd9d4836bdd249c6d511ebc6c0df17fbc1b9df96c3d781
-SIZE (ecj-4.5.jar) = 1470676
Index: gcc48/pkg-plist
===
--- gcc48/pkg-plist (revision 310417)
+++ gcc48/pkg-plist (working copy)
@@ -50,7 +50,6 @@
 %%JAVA%%bin/jv-convert%%SUFFIX%%
 %%JAVA%%bin/rebuild-gcj-db%%SUFFIX%%
 %%JAVA%%libdata/pkgconfig/libgcj-4.8.pc
-%%JAVA%%share/java/ecj.jar
 %%JAVA%%share/java/libgcj-%%GCC_VERSION%%.jar
 %%JAVA%%share/java/libgcj-tools-%%GCC_VERSION%%.jar
 @exec if type ccache-update-links >/dev/null 2>&1; then ccache-update-links 
-v; fi
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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 inscribing hints
> in the binaries to look first in the right gcc port directories.  But
> if we update lang/gcc from 4.6.x to another major version (e.g.
> 4.7.x), the directory changes, and linking for the old binaries will
> fail.  So let me qualify my earlier answer: you can keep the old
> software working with minimal intervention, for example, by adding a
> symlink from the old directory to the new one.

What we could do, for the canonical version of GCC (lang/gcc,
USE_GCC=yes) is install those libraries into /usr/local/lib
instead of /usr/local/lib/gccXY as we are doing for lang/gccXY.

What do you think?

>>> I had patches to do this even without pkgng, but it made things a 
>>> little more complicated, and didn't seem to be a high priority, so I 
>>> didn't pursue it.  If people feel that it is important, I could work 
>>> with Gerald to revive that
>> Making this change now would benefit a lot of people, now.
> Okay, but since I'm not in charge either, it will require (at least)
> Gerald's consent.

That would be cool.  Bapt wanted to look into this as well a few
months ago, so perhaps the two of you can (should?) sync before
proceeding?

Gerald

PS: I don't think we should go for the other option, static linking.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 bootstrap the environment to easily use wine from 
> FreeBSD/amd64.  There is also a script to install the i386 nVidia 
> graphic drivers so that wine has access to nVidia accelerated graphics 
> from FreeBSD/amd64.
> 
> I would like to propose this port gets included in the port's collection 
> and would like to get feedback, your comments please :-).

I would say, go ahead and send-pr the port (without the nVidia parts
for now).

If nobody else bites within two weeks of you sending it, share the number 
with me, and I'll give it a try.  I am sure that, once in, there will be 
many aspects we'll get feedback on and further tweaks and improvements, 
but it seems this is relatively widely used and useful, so let's make
it port of the ports collection and jointly take it from there.

>  - Can only be compiled in an i386 environment, but the resulting package is 
> *intended* for amd64 (although works fine in an i386 environment)
>  - If, somehow, there is a recursive calling of wine programs then 
> LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.  
>  - The pkgng ports cannot be installed in an i386 environment as they are 
> labelled for amd64.  

My primary question at this point, and to this group, is how to
actually name such a port?  

It probably makes sense to focus on wine-devel, initially, but 
given that it's really the 32-bit version that is intended for
the 64-bit OS, how to best reflect that?

wine-devel-fbsd64 as per the current name?  wine-devel-32on64?...??

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: bsd.gcc.mk: USE_FORTRAN.

[Gerald Pfeifer]

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 look into this.  But, how about the run-time
dependency?  Those ports that you have in mind, don't they have
any dependency on one of the GCC run-time libraries?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46 dependency loop on lang/gcc

[Gerald Pfeifer]

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 portmaster could tell us where the loop comes from?  I
looked at the -v option, but that one did not seem to provide this
information and I feel stuck right now.

On Mon, 27 Aug 2012, David Wolfskill wrote:
> FWIW, on the machine on which I'm writing this note, I successfully
> performed an:
> 
> Upgrade of gcc-4.6.4.20120608 to gcc-4.6.4.20120817

Thanks for the confirmation, David.

Is it possible you have some special setting somewhere, Robert,
like USE_GCC=... as a global setting somewhere?

(Though, shouldn't even that work with portmaster assuming that this
part of the process, forcing deinstallation of the old version and
installing a new package, does not depend on "any" other ports?)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

lang/gcc47 upgrade problems (was: lang/gcc46 dependency loop on lang/gcc)

[Gerald Pfeifer]

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.

Any chance to see where this dependency for lang/gcc47 on
itself is coming from?  Especially with the report that an
install followed directly by an upgrade triggers this?

On Wed, 29 Aug 2012, 唐 剑锋 wrote:
> I have tested in a new freebsd 9.0. 
> only install gcc47 then upgrade it.

Does this also happen if you do not have USE_GCC=4.7 in 
/etc/make.conf?

What exactly is the effect of that?  Does this not build
every other port with a dependency on gcc47?  If so, when
portupgrade temporarily remove gcc47, won't this impact
anything that portupgrade runs afterwards?

Is 

  pkg_delete: package 'gcc-4.7.2.20120818' is required by these other packages
  and may not be deinstalled (but I'll delete it anyway):
  .. (depends packages ignore)

the key perhaps?

Gerald___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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 versioning (like gcc) are a bad idea. It's much better for
> users to be able to tie their installations to a particular version, and
> then only update when they need to. The fact that someday in the future
> users who innocently upgrade lang/gcc will suddenly find that everything
> relying on libgcc at runtime is now broken pretty much speaks for itself.

The fact that I would consider that, was not supposed to imply
breakage. :-)  I was more thinking better optimization and other
benefits.

In my day job, we have been doing upgrades from GCC 4.x to GCC 4.x+y
run-times quite successfully and without any breakage more than once.
And we've got many, quite many, users.

In other words, if there is a challenge it's not GCC per se, more 
our packaging of it (and some work Bapt is doing on the packaging
infrastructure should help with that).

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46 building stuff in $TMPDIR

[Gerald Pfeifer]

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 lose a lot of speed.
> Have you measured that?

1:15:27 for a full build of lang/gcc48 when /tmp was used, versus
1:34:25 on the same system when TMPDIR was set to a network drive.

This is just one scenario, and it may go both ways.  It does show
that having temporary files on fast storage is significant.

[i386 host, build including Java, storage on spindles.]

>> Finally, you indicated that you also saw Java create a large
>> temporary file.  If you want to avoid building Java, the GCC
>> ports have an option to disable Java.
> Reducing functionality to handle build infrastructure problems is
> not a desirable solution. But thanks for the response in any case. :)

Reducing functionality if that cuts the cost of building in half
and you do not actually use that functionality (only a single port
does, from what I know) actually looks quite desirable to me. ;-)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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 tree had been completely
> unfrozen. It is likely that only a few dependent ports will have to be
> changed. You can make this change now, simply by removing lang/gcc46
> and installing lang/gcc, and then rebuilding all dependent ports (this
> last step may not be necessary in many cases, but it is better to be
> safe).

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.

> Or you can try something like the attached patch, which will fix the
> dependency accounting -- but you will then have to replace
> _GCC_BUILD_DEPENDS with _GCC_PORT_DEPENDS (the latter will then be a
> misnomer) in math/atlas, math/atlas-devel, math/gotoblas, math/R,
> net-p2p/eiskaltdcpp-* (and soon perhaps also lang/libobjc2, if it is
> altered to use USE_GCC, which seems likely).

Sadly there are a number of ports using _GCC_BUILD_DEPENDS even though
by virtual of its name this is an internal (to bsd.gcc.mk) variable. I
am keeping this for now and will address this in a better manner and
work with the maintainer(s) of affected ports.

For the time being, my patch below is an extended version of what
Brendan shared and addresses (or tries to) issues he mentioned.

Gerald

Index: bsd.gcc.mk
===
--- bsd.gcc.mk  (revision 301695)
+++ bsd.gcc.mk  (working copy)
@@ -178,29 +178,36 @@
 . if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
 .  if ${OSVERSION} < ${_GCCVERSION_${v}_L} || ${OSVERSION} > 
${_GCCVERSION_${v}_R}
 V:=${_GCCVERSION_${v}_V:S/.//}
-_GCC_BUILD_DEPENDS:=   gcc${V}
 _GCC_PORT_DEPENDS:=gcc${V}
+.   if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
+_GCC_PORT:=gcc
+.   else
+_GCC_PORT:=gcc${V}
+.   endif
 CC:=   gcc${V}
 CXX:=  g++${V}
 CPP:=  cpp${V}
 .   if ${_USE_GCC} != 3.4
-CFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-LDFLAGS+=  -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+CFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
+LDFLAGS+=  -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
 .if defined (USE_FORTRAN)
 .if ${USE_FORTRAN} == yes
-FFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+FFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
 .endif
 .endif
+# The following is for the sakes of some ports which use this without
+# ever telling us; to be fixed.
+_GCC_BUILD_DEPENDS:=   ${_GCC_PORT_DEPENDS}
 .   endif
 .  endif
 . endif
 .endfor
 .undef V
 
-.if defined(_GCC_BUILD_DEPENDS)
-BUILD_DEPENDS+=
${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+.if defined(_GCC_PORT_DEPENDS)
+BUILD_DEPENDS+=${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
 . if ${_USE_GCC} != 3.4
-RUN_DEPENDS+=  ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+RUN_DEPENDS+=  ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
 .  if ${_USE_GCC} != 4.2
 # Later GCC ports already depend on binutils; make sure whatever we
 # build leverages this as well.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc rumdependencies?

[Gerald Pfeifer]

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 they find this to be a problem: they can remove lang/gcc46 and
> replace it with lang/gcc.

You may have noticed that lang/gcc46 has signficiantly slowed down
in it getting updates the last couple of months.  That was by design,
since I know a larger number of users is having this as the default
version of GCC.

For ports building clusters and to simplify things for non-expert
users, or users just going for the default, indeed dragging in
lang/gcc by default, not lang/gcc46 (or later lang/gcc47) makes
sense and the patch below should do this.  

Feedback welcome!

>> Maybe it would be good to move current lang/gcc46 to lang/gcc46-devel
>> and rename lang/gcc to lang/gcc46?
> No, because in time lang/gcc will become a stable release of 4.7.x,
> and so on ...

Exactly!  I _am_ thinking to rename lang/gcc48 to lang/gcc48-devel,
and perhaps do similarly for lang/gcc47 as well.  Thoughts?

Gerald

PS. The _GCC_BUILD_DEPENDS assignment below prevents breakage of
some ports.  I plan on addressing this in a nicer manner, but prefer
to separate the two changes and proceed with this first change rather
sooner than later.


Index: bsd.gcc.mk
===
--- bsd.gcc.mk  (revision 301695)
+++ bsd.gcc.mk  (working copy)
@@ -178,29 +178,36 @@
 . if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
 .  if ${OSVERSION} < ${_GCCVERSION_${v}_L} || ${OSVERSION} > 
${_GCCVERSION_${v}_R}
 V:=${_GCCVERSION_${v}_V:S/.//}
-_GCC_BUILD_DEPENDS:=   gcc${V}
 _GCC_PORT_DEPENDS:=gcc${V}
+.   if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
+_GCC_PORT:=gcc
+.   else
+_GCC_PORT:=gcc${V}
+.   endif
 CC:=   gcc${V}
 CXX:=  g++${V}
 CPP:=  cpp${V}
 .   if ${_USE_GCC} != 3.4
-CFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-LDFLAGS+=  -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+CFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
+LDFLAGS+=  -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
 .if defined (USE_FORTRAN)
 .if ${USE_FORTRAN} == yes
-FFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+FFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
 .endif
 .endif
+# The following is for the sakes of some ports which use this without
+# ever telling us; to be fixed.
+_GCC_BUILD_DEPENDS:=   ${_GCC_PORT_DEPENDS}
 .   endif
 .  endif
 . endif
 .endfor
 .undef V
 
-.if defined(_GCC_BUILD_DEPENDS)
-BUILD_DEPENDS+=
${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+.if defined(_GCC_PORT_DEPENDS)
+BUILD_DEPENDS+=${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
 . if ${_USE_GCC} != 3.4
-RUN_DEPENDS+=  ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+RUN_DEPENDS+=  ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
 .  if ${_USE_GCC} != 4.2
 # Later GCC ports already depend on binutils; make sure whatever we
 # build leverages this as well.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46 building stuff in $TMPDIR

[Gerald Pfeifer]

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 files in /tmp (I think it's
> actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which
> are small, but one of which grew to over 64M, which is what caused my
> build to fail. It also creates a variety of other files, including .o,
> .c, .ld, .le, .zip, etc.
> 
> The java OPTION also creates some pretty big jar directories, I had one
> grow to 49M, which didn't crash my build, but might blow up someone with
> a smaller /tmp.
> 
> 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 lose a lot of speed.

Also, while I understand your situation, I am very hesitant to change
any defaults given that I have not seen any other user reports, not
even upstream.


Note: according to the GCC documentation

If `TMPDIR' is set, it specifies the directory to use for temporary
files.  GCC uses temporary files to hold the output of one stage of
compilation which is to be used as input to the next stage: for
example, the output of the preprocessor, which is the input to the
compiler proper.

Does it make a difference for you if you set TMPDIR to some location
where you have more storage?

On Tue, 10 Jul 2012, Doug Barton wrote:
> Just tried building the latest, same error. Did I misunderstand that
> something was supposed to be different?

I believe lang/gcc47 has seen a split of one large, automatically
generated, source file which is what you may have run into.  So going
for that (and I plan on moving lang/gcc to GCC 4.7 in the not too far
future) could be one option.

Another might be reducing the amount of parallel building on your
system.

Finally, you indicated that you also saw Java create a large
temporary file.  If you want to avoid building Java, the GCC
ports have an option to disable Java.  Let me actually take
this as a trigger to convert this to the new options framework.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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
infrastructure was not exactly helpful.  Ideally I would want
something like gcc46-runtime and gcc46-java and gcc46 itself,
where -runtime is a hard dependency for gcc46 and -java optional.

Short of building lang/gcc46 a couple of times via slave ports and 
packaging different aspects by virtue of different slave ports, or
having gcc46 also include the contents of gcc46-runtime, the introduction 
of a gcc46-DONT-USE-JUST-USED-FOR-SUBPACKAGES dummy port was the only
idea I came up with.  None of the three approaches really convinced me.

On Sun, 10 Jun 2012, Baptiste Daroussin wrote:
> Yes that would be a lot of but it is the way we are doing. the upcoming 
> stagedir will open the door to easy package splitting and then allow 
> easily to split gcc into something like gcc-libs and gcc package or 
> something like that.

Lovely.  Looking forward to that!

(Chris also indicated he had an idea, let's see.  Whatever works. ;-)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46 building stuff in $TMPDIR

[Gerald Pfeifer]

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
stash really temporary things (coming from an individual invocation
of GCC such as assembly files if any) in /tmp for short periods of
time.

I am not aware of anything we could do beyond what I already have
in the port, but then this is the first time I hear about this, in
the context of FreeBSD and also upstream.

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?

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: WITH_GCC

[Gerald Pfeifer]

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 defined?
> 
> This should be split out.  The use case is to make it possible to set 
> something like the following in make.conf:
>
> CFLAGS.gcc46+= -fearlier-gcc-fails-with-this-flag-but-I-want-it-with-gcc46

I see!  The only question I have is whether, given there is also clang, 
this is really best suited for Mk/bsd.gcc.mk, or this should rather
become part of the general Mk/bsd.port.mk?

To me it looks more like the latter, Mk/bsd.port.mk, but if not for
some reason, please add a comment to the top of the file Mk/bsd.gcc.mk
and commit this part.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: WITH_GCC

[Gerald Pfeifer]

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 opposed to the
patch, but feel it may be better broken up in distinct and independent
changes.  Some should go through a full cluster build.  And some
give me serious headache.

On Fri, 11 May 2012, Andriy Gapon wrote:
> Hopefully it should handle the bootstrapping better by accounting for 
> lang/gcc*
> ports dependencies and avoiding creating any circular dependencies.
> For simplicity the GCC ports and their dependencies are forced to be 
> built with the base GCC, although this does not have to be required.

Looking at the patch, there is no documentation.  Can you please add
some comments to document the new setting and how it interacts with
what is in place as of today?

> +.if defined(WITH_GCC) && ${PORTNAME} != gcc
> +
> +# See if we can use a later version or exclusively the one specified.
> +_WITH_GCC:=  ${WITH_GCC:S/+//}

Shouldn't there first be some code that handles the case where USE_GCC
and WITH_GCC are specified at the same time?

Also, is this duplication of code really necessary between the two
settings, or could that be avoided by setting USE_GCC appropriately
under the right conditions ("if and only if...") or something like
that?

>  .if defined(_GCC_ORLATER)
> +. if defined(_WITH_GCC)
> +.  if ${_USE_GCC} < ${_WITH_GCC}
> +_USE_GCC:= ${_WITH_GCC}
> +.  endif
> +. endif

When can this happen?  And can this be handled earlier, cf. above?

> -_GCC_BUILD_DEPENDS:= gcc${V}
>  _GCC_PORT_DEPENDS:=  gcc${V}
> +.   if ${V} == ${GCC_DEFAULT_V}
> +_GCC_BUILD_DEPENDS:= gcc
> +.   else
> +_GCC_BUILD_DEPENDS:= gcc${V}
> +.   endif

Isn't this an unrelated change to what you are mainly working on?

I'd prefer to avoid that, unless there is a good reason.  And if
there is, I'm open (and like) to see this go in separately.

> +_GCC_OWN_DEPENDS!= (cd ${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS} && ${MAKE} -V
> _UNIFIED_DEPENDS)
> +.   for _CURDIR in ${.CURDIR} # only loop variable are expanded in variable
> modifiers
> +.   if ${_GCC_OWN_DEPENDS:M*\:${_CURDIR}} != ""
> +.undef _GCC_BUILD_DEPENDS
> +.undef _GCC_PORT_DEPENDS
> +.   else

Headache, major headache. :-)  What is this for, do we really need
it, and why, and can this be done differently?

> +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 defined?

Gerald

PS: I won't be able to do FreeBSD work the coming two weeks (at all, 
probably) but am very open to working with you and this change or
changes split out of that as well as other changes. Do not read
anything into it if responses may take a bit at times. :-)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Where are conventions like -devel ports documented?

[Gerald Pfeifer]

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 this is an omission, can someone more closely involved than
I have been so far donate a paragraph or two?)

Gerald

PS: I am thinking to split the existing emulators/wine port into
two, the regular one (tracking releases of Wine) and a -devel port
that tracks the bi-weekly snapshots that will lead to the next
release in a year or two.  Somehow I would prefer something like
wine-stable / wine instead of wine / wine-devel, but the latter is
more in line with how we are doing things, right?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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

> Why?  Given that the typical build is 'make && make install && make clean',
> patching ChangeLog seems rather odd.  The same question applies to the
> other ChangeLog diffs that I've removed.

I was going for the full upstream changeset, consuming that directly.
Based on your feedback I just noted the upstream revision ids and omitted
the ChangeLog patches.

Thanks,
Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc on freebsd 10

[Gerald Pfeifer]

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 small trouble with it was that the resulting 
> files/patch-freebsd10 had the dos line endings.

Hmm, I think that must have happened when I mailed it (though no
Windows machine was involved)?  The patch as I applied it should
not have those.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 updated accordingly,
> it will include the fixes.  In the meantime, I think Gerald was
> waiting for Martin to incorporate the patch to adjust the
> run-autotools-fixup target in ports/Mk/bsd.port.mk

As usual, Brendan is right on target. :-)  If you guys would like
to test the attached patch for lang/gcc, it does allow that port
to build on a FreeBSD 10 system for me, and if I get independent
confirmation in the next three days it'll be in before holiday
season.

GeraldIndex: files/patch-freebsd10
===
RCS file: files/patch-freebsd10
diff -N files/patch-freebsd10
0a1,873
> Upstream SVN commit 181536.
> 
> Index: libtool.m4
> ===
> --- libtool.m4(revision 181535)
> +++ libtool.m4(revision 181536)
> @@ -2273,7 +2273,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[[123]]*) objformat=aout ;;
> +freebsd[[23]].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -2291,7 +2291,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2*)
> +  freebsd2.*)
>  shlibpath_overrides_runpath=yes
>  ;;
>freebsd3.[[01]]* | freebsdelf3.[[01]]*)
> @@ -4804,7 +4804,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs 
> $deplibs $linker_flags'
>_LT_TAGVAR(hardcode_direct, $1)=yes
>_LT_TAGVAR(hardcode_minus_L, $1)=yes
> @@ -5751,7 +5751,7 @@
>  esac
>  ;;
>  
> -  freebsd[[12]]*)
> +  freebsd2.*)
>  # C++ shared libraries reported to be fairly broken before
>   # switch to ELF
>  _LT_TAGVAR(ld_shlibs, $1)=no
> Index: libgomp/configure
> ===
> --- libgomp/configure (revision 181535)
> +++ libgomp/configure (revision 181536)
> @@ -9317,7 +9317,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
>hardcode_direct=yes
>hardcode_minus_L=yes
> @@ -10230,7 +10230,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[123]*) objformat=aout ;;
> +freebsd[23].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -10248,7 +10248,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2*)
> +  freebsd2.*)
>  shlibpath_overrides_runpath=yes
>  ;;
>freebsd3.[01]* | freebsdelf3.[01]*)
> @@ -13164,7 +13164,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>archive_cmds_FC='$LD -Bshareable -o $lib $libobjs $deplibs 
> $linker_flags'
>hardcode_direct_FC=yes
>hardcode_minus_L_FC=yes
> @@ -13869,7 +13869,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[123]*) objformat=aout ;;
> +freebsd[23].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -13887,7 +13887,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2*)
> +  freebsd2.*)
>  shlibpath_overrides_runpath=yes
>  ;;
>freebsd3.[01]* | freebsdelf3.[01]*)
> Index: libgomp/ChangeLog
> ===
> --- libgomp/ChangeLog (revision 181535)
> +++ libgomp/ChangeLog (revision 181536)
> @@ -1,3 +1,7 @@
> +2011-11-20  Andreas Tobler  
> +
> + * configure: Regenerate.
> +
>  2011-10-26  Release Manager
>  
>   * GCC 4.6.2 released.
> Index: libquadmath/configure
> ===
> --- libquadmath/configure (revision 181535)
> +++ libquadmath/configure (revision 181536)
> @@ -8727,7 +8727,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
>hardcode_direct=yes
>hardcode_minus_L=yes
> @@ -9643,7 +9643,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[123]*) objformat=aout ;;
> +freebsd[23].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -9661,7 +9661,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2

Re: lang/gcc on freebsd 10

[Gerald Pfeifer]

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 being the fast, aggressive one.  In consequence,
> lang/gcc46 has already been fixed with regard to FreeBSD 10, whereas
> this likely will take another month or so for lang/gcc when the next
> upstream release hapens.
> 
> (Had I better network connectivity right now, I might try the backport, 

I managed to get a somewhat decent connection now (and until Thursday).

Want to give the attached patch against lang/gcc a try?  It passes my
tests, but I'd prefer to get confirmation from someone directly affected
before committing it.

GeraldIndex: files/patch-freebsd10
===
RCS file: files/patch-freebsd10
diff -N files/patch-freebsd10
0a1,873
> Upstream SVN commit 181536.
> 
> Index: libtool.m4
> ===
> --- libtool.m4(revision 181535)
> +++ libtool.m4(revision 181536)
> @@ -2273,7 +2273,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[[123]]*) objformat=aout ;;
> +freebsd[[23]].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -2291,7 +2291,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2*)
> +  freebsd2.*)
>  shlibpath_overrides_runpath=yes
>  ;;
>freebsd3.[[01]]* | freebsdelf3.[[01]]*)
> @@ -4804,7 +4804,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs 
> $deplibs $linker_flags'
>_LT_TAGVAR(hardcode_direct, $1)=yes
>_LT_TAGVAR(hardcode_minus_L, $1)=yes
> @@ -5751,7 +5751,7 @@
>  esac
>  ;;
>  
> -  freebsd[[12]]*)
> +  freebsd2.*)
>  # C++ shared libraries reported to be fairly broken before
>   # switch to ELF
>  _LT_TAGVAR(ld_shlibs, $1)=no
> Index: libgomp/configure
> ===
> --- libgomp/configure (revision 181535)
> +++ libgomp/configure (revision 181536)
> @@ -9317,7 +9317,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
>hardcode_direct=yes
>hardcode_minus_L=yes
> @@ -10230,7 +10230,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[123]*) objformat=aout ;;
> +freebsd[23].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -10248,7 +10248,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2*)
> +  freebsd2.*)
>  shlibpath_overrides_runpath=yes
>  ;;
>freebsd3.[01]* | freebsdelf3.[01]*)
> @@ -13164,7 +13164,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do not have this feature.
> -freebsd2*)
> +freebsd2.*)
>archive_cmds_FC='$LD -Bshareable -o $lib $libobjs $deplibs 
> $linker_flags'
>hardcode_direct_FC=yes
>hardcode_minus_L_FC=yes
> @@ -13869,7 +13869,7 @@
>  objformat=`/usr/bin/objformat`
>else
>  case $host_os in
> -freebsd[123]*) objformat=aout ;;
> +freebsd[23].*) objformat=aout ;;
>  *) objformat=elf ;;
>  esac
>fi
> @@ -13887,7 +13887,7 @@
>esac
>shlibpath_var=LD_LIBRARY_PATH
>case $host_os in
> -  freebsd2*)
> +  freebsd2.*)
>  shlibpath_overrides_runpath=yes
>  ;;
>freebsd3.[01]* | freebsdelf3.[01]*)
> Index: libgomp/ChangeLog
> ===
> --- libgomp/ChangeLog (revision 181535)
> +++ libgomp/ChangeLog (revision 181536)
> @@ -1,3 +1,7 @@
> +2011-11-20  Andreas Tobler  
> +
> + * configure: Regenerate.
> +
>  2011-10-26  Release Manager
>  
>   * GCC 4.6.2 released.
> Index: libquadmath/configure
> ===
> --- libquadmath/configure (revision 181535)
> +++ libquadmath/configure (revision 181536)
> @@ -8727,7 +8727,7 @@
>;;
>  
>  # Unfortunately, older versions of FreeBSD 2 do

Re: lang/gcc on freebsd 10

[Gerald Pfeifer]

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 the fast, aggressive one.  In consequence,
lang/gcc46 has already been fixed with regard to FreeBSD 10, whereas
this likely will take another month or so for lang/gcc when the next
upstream release hapens.

(Had I better network connectivity right now, I might try the backport, 
but really the use case for lang/gcc at this point is not users of
FreeBSD 10.  That's going to change with the changes to Mk/bsd.gcc.mk
that we discussed on this list the last couple of days, and that will
not happen before it builds on FreeBSD 10.)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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 updated very rarely.

Any other version of lang/gcc you need to use is indicative of an issue 
with some other port (short of the GNUstep ports which we are in the 
process of addressing now that lang/gcc also provide Objective-C).


In case you are interested, I have been spending quite some effort
over the last years to minimize the number of such ports and here
is the list of remaining ones:

  cad/salome/Makefile.ext   USE_GCC=4.4

  cad/sceptre/Makefile  USE_FORTRAN=g77
  graphics/p5-PGPLOT/Makefile   USE_FORTRAN=g77
  science/elmer-matc/Makefile   USE_FORTRAN=g77
  science/elmerpost/MakefileUSE_FORTRAN=g77

Without these, lang/gcc44 and lang/gcc34, respectively, could be 
obsoleted and removed.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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. stated
earlier in the thread, if you want to be 100% sure rebuilding all
dependent ports is always the safer approach.)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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. :-)  Replace lang/gcc46 by lang/gcc on
your local systems, Kevin and Jason, and that (not lang/gcc46) will
be used henceforth.

There is a small issue in that this will not be recorded properly as
a dependency when you build packages, but apart from that (if you use
ports or ensure the lang/gcc package is present wherever you install
things built that way, you should be good.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc46

[Gerald Pfeifer]

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 USE_FORTRAN=yes both will
automagically just pull in lang/gcc instead of lang/gcc46 by default.

That's the plan.  It's taken a bit longer than I had hoped (for a
number of reasons), but we are nearly there. ;-)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 done after installation, 
> when, I afraid, adding RUN_DEPEND at this stage doesn't help, so this 
> automatic should make all depends-related work (+REQUIRED_BY / +CONTENT) 
> "by hands".

I think you have a good observation here.  One way of addressing it,
which would be simpler and less effort and risk, is to split the large
lang/gcc ports into smaller bits, including a run-time port, once the
work on this infrastructure (that Linux distributions have been using
for more than ten years) is in place.

In other words, have something like a gcc-runtime package that falls
out of the lang/gcc port and covers all those needs.  (That's not the
minimum, assuming we still have something -- bet it GCC 4.2 or LLVM
based in the base system -- but quite small.)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to best run a script post installation _and_ deinstallation?

[Gerald Pfeifer]

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-deinstall.html

Yes and no (to both questions).

I have been looking for a silver bullet that avoids having
  (a) something in the post-install target plus an @exec and an @unexec
  and thus redundancy, or
  (b) two extra scripts and thus two extra files in the port.  

Alas, I failed at that, and Emanuel convinced me that apparently there
is no way to avoid one of these two deaths.

That looks like a nice project for someone to improve our general
infrastructure along these lines.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 hope we can have another -exp run soon that addresses this.

Matthias, sorry for not getting to this earlier.  If you look at
Mk/bsd.port.mk, there is a line

  GCCVERSION_040200=  700042 99 4.2

which indicates that GCC 4.2 has been in the base system starting
with FreeBSD 7.0 (and that magic 42 marker) until the rest of times.

Can you advise which value of __FreeBSD_version to use?  The official
list at
  
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html
does not have a reference from what I can see.

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

How to best run a script post installation _and_ deinstallation?

[Gerald Pfeifer]

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 works for installation:

Index: Makefile
===
< post-install:
---
> post-install: ccache-update
181a182,186
> post-deinstall ccache-update:
>   @if [ -x ${PREFIX}/bin/ccache-update-links ]; then \
>   ${PREFIX}/bin/ccache-update-links -v; \
>   fi
> 

It does not cover de-installation which raises two questions:

 1. Why don't we have a post-deinstall target?

 2. How is the task best accomplished?

Gerald


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gcc-4.4.6.20101012 marked broken?

[Gerald Pfeifer]

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)
> - lang/gcc44 (marked as IGNORE)
> 
> Is it safe to remove this port? isn't gcc part of the core operating 
> system? I'm not sure which port went to install this but I'm hesitant to 
> remove it and break my ability to compile.

lang/gcc44 is not part of the core operating system, but one of the
many the programs offered via the FreeBSD Ports Collection.

If you want to use GCC on FreeBSD, I recommend to go for lang/gcc45
(short: gcc45).  I do not know what caused the installation of gcc44
on your system, but gcc45 should be strictly preferrable and not needed
by anything else.

Gerald

PS: There is a suggested fix for the issue around lang/gcc44 that I
will give another try after it originally failed for me, but that
does not change any of the above.
-- 
Gerald (Jerry) Pfeifer   ger...@pfeifer.com   http://www.pfeifer.com/gerald/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 "uglier" pieces remain in the slave port itself.

Gerald
k
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Gerald Pfeifer]

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 my open PRs. ;-)

Gerald
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"