supports them. This is determined by running ``configure --help'' in
do-configure target and set the shell variable _LATE_CONFIGURE_ARGS
which is then passed to CONFIGURE_ARGS.
- Remove --mandir and --infodir in ports' Makefile where applicable
Few ports use REINPLACE_CMD to achieve the same effect, remove them too.
- Correct some manual pages location from PREFIX/man to MANPREFIX/man
- Define INFO_PATH where necessary
- Document that .info files are installed in a subdirectory relative to
PREFIX/INFO_PATH and slightly change add-plist-info to use INFO_PATH and
subdirectory detection.
PR: ports/111470
Approved by: portmgr
Discussed with: stas (Mk/*), gerald (info related stuffs)
Tested by: pointyhat exp run
application and man pages for gappletviewer43, gjar43, gjarsigner43,
gjavah43, gkeytool43, gnative2ascii43, gorbd43, grmid43, gserialver43,
and gtnameserv43.
This has a patch of mine to account for the removal of /usr/bin/objformat
on 7-CURRENT and defaults to elf instead of aout in this case.
Add a temporary patch to fix the bootstrap on i386.
This adds a couple of further programs related to Java language support,
specifically gjar, gjavah, gnative2ascii, gorbd, grmid, gserialver, and
gtnameserv.
Adjust pkg-plist to remove some secondary programs which we no longer
provide after the import of the Eclipse Java frontend.
Properly set INFO for those cases where we actually do not build libgomp,
and thus not libgomp.info either.
Move ia64 to NOT_FOR_ARCHS from BROKEN, like we did with lang/gcc43.
Remove the cklatest target and files/patch-gengtype-yacc.y.
whether it is our kernel/userland, the hardware, or something else at fault
and nobody on our side nor upstream seems to have any interest.
Discussed with: kris
This adds a libgomp info page (the other changes to INFO and MAN are
just to sort these two properly) and we need to add a temporary patch
to fix an issue triggered by FreeBSD headers.
snapshot of GCC 4.3.0; repocopied over from lang/gcc42.
Sadly we now have an unconditional dependency on math/libgmp4 and
math/mpfr. On the positive side this allows us to always build the
Fortran frontend.
PR: 104683
version number to libdata/pkgconfig/libgcj.pc. Fix packaging on amd64
on the way (enabling Java actually was a noop, except for pkg-plist).
Update lang/gcc41 to the 20061013 snapshot of GCC 4.1.2.
These changes allow us to remove the CONFLICT between lang/gcc41 and
lang/gcc42 when building with Java support (the default on i386).
Approved by: portmgr (erwin)
caused by include/ffi.h.
Enable libgcj on amd64 in addition to i386.
Remove the hack we had used to rename man pages to match the actual
names of binaries (back when GCCs configure mechanism failed to do so).
two cases where the common (file) namespace was polluted by Java-specific
files.
Disable building libgomp on FreeBSD 4.x and early versions of FreeBSD 5.0
due to pthread-related build issues there.[1]
Reported by: kris (pointyhat) [1]
No longer create ${PREFIX}/libdata/ldconfig, the issue has been addressed
in Mk/bsd.port.mk now.
Be more friendly for additional patches.
Submitted by: maho (implicitly)
Simplify the subdirectory we use for GCC-specific libraries and include
files from gcc/${CONFIGURE_TARGET}/${PORTVERSION} to gcc-${PORTVERSION}.
Remove the hack to set RANLIB=: now that this has been addressed upstream.
bootstrap-lean is back, which means quite a bit less disk space used when
building this port. Also, Java comes with new applications gappletviewer42,
gjarsigner42, and gkeytool42 and a new libgcj-tools-4.2.0.jar.
Employ the new USE_LDCONFIG feature, which allows us to get rid of the
various, much more manual and error-prone hacks we needed so far.
Reviewed by: flz (for lang/gcc40)
Java support is back (on i386), and all those additional libtool
files we are currently installing as part of libgcj will be gone
with next week's snapshot.
The spamming of $PREFIX/include/ssp is now finally gone after my reports
upstream, which allows us to restrict the conflict with gcc-4.1.* to the
case where we build Java.
Convert the build-time dependency on math/mpfr to a full one, since the
Fortran frontend also needs this at run time.
Always build both shared and static libraries instead of having these as
two exclusive options defaulting to the former.
Remove bogus USE_X11 (which was not used by default nor any other port).
No longer hardcode the version number in LATEST_LINK.
Remove USE_REINPLACE= as advised by new portlint. Also note that at
least some of the installation hierarchy problems with libgomp have
been fixed now due to my report upstream.
Improve packaging by using @dirrm include/ssp instead of speculative
removal. Remove broken removal of the info/gcc42 directory; this has
to be handled by Mk/bsd.ports.mk.
Install the .info files of the lang/gcc40 port in a port-specific
subdirectory, and move include/mf-runtime.h into a version specific
directory. This allows us to remove the conflicts with lang/gcc33,
lang/gcc41 and lang/gcc42.
Also, convert pkg-plist to use a new substitution (%%SUFFIX%%) instead
of hardcoding the version number 40.
Unfortunately, we have to disable building Java since installation of
libgcj consumes insane amounts of memory and thus fails on machines with
less than 1GB of RAM.
testsuite; since this is not needed for regular operation, just disable
it in the port, but keep the correct data in distinfo, in case someone
wants to obtain and verify it nevertheless.
PR: 89128
Reported by: pointyhat
build with GCC 2.95 that I already submitted upstream as well).
Add a long missing dependency on USE_ICONV=yes.[1]
PR: 88894 [1]
Submitted by: Björn König" <bkoenig@cs.tu-berlin.de> [1]
due to the stabilization work for the 4.1.0 release and also addresses
some hierarchy problems I had reported (and which we no longer need to
work around).
problems should be resolved now.
Prevent running ranlib during installation to unbreak user mode
installations which now install libraries with permissions 444.
We now also need the math/mpfr port to build the Fortran frontend.[1]
PR: 85495 [1]
On the way, upgrade to the 20050819 snapshot of GCC 4.1 where the Java
libraries finally build (progress!) but fail due to a problem with the
installation. If someone wants to force installation, setting SHAREMODE
to allow writing should suffice.
Approved by: portmgr (krion)
Replace the WITHOUT_LIBJAVA knob by WITHOUT_JAVA which also disables
building the compiler and tools proper and avoids fetching the entire
Java frontend and library tarball.
Remove bogus ${PREFIX}/share/classpath/api directory that libjava adds
these days.
Make the (optional) handling of the Fortran and Java frontends easier
to understand.
end of pkg-plist since that broke the /sbin/ldconfig invocations the
ports machinery added there (before we'd get a chance).[1]
Reported by: dinoex [1]
Directly install libraries into a port-specific location instead of
moving them there after the original installation. This is simpler
and also avoids the problem where the port would overwrite/remove an
existing copy of libiberty.a, which boils down to a true conflict.
pages on systems with an old version of Perl, once and for all and forever.
Reenable building libjava where appropriate, now that this has been fixed
upstream. And treat Fortran libraries exactly like other language support
libraries, reducing conflicts with other gcc ports and getting rid of the
libtool archives on the way.
Add a conflict with the gcc34 port and address portlint warnings.
Simplify the handling of libraries which are not installed in all
configurations and put all libgcj libraries in the same directory
as all others, getting rid of the libtool .la archives on the way.
No longer install fsf-funding.7 gfdl.7 gpl.7, remove some cruft from
the post-install target, and simplify generation of the dynamic parts
of the packaging list.
remove inflamatory comment.
Remove BROKEN from sparc64 and simplify special case handling of
libgcj on ia64 and sparc64.
USE_SIZE is now the default, no need to specify it explicitly.
Remove WANT_THREADS_SUPPORT knob, which should be a no-op by now.
quite some build time and also disk. Make this the default on sparc64 and
ia64 where libgcj has not been ported to and thus fix long-standing packaging
issues on these two platforms.
On the way, update to the 20040310 snapshot of GCC 3.4.0.
PR: 63427 (mostly)
Given that I am now responsible for snapshot generation on gcc.gnu.org,
remove the feature to obtain sources from GCC CVS. Mark broken on amd64
(which used to be called x86_64).
Port the following two fixes from the lang/gcc33 port:
2004/02/08: Fix build on systems without a decent version of Perl.
2004/01/30: The Fortran frontend binary is called g77, not f77.
Merge in my 2004/01/17 change to the gcc33 port to configure with
--program-suffix and related and further simplifications.
Merge in my 2004/01/13 change to the gcc33 port to make the automatic
generation of the package list for libraries and include files more
failure tolerant, so that at least `make install` now works on sparc64.
Merge in my 2004/01/05 change to the gcc33 port to combine and simplify
the post-install handling of target libraries and GCJ include files.
libgcj still is not supported and packaging is broken on sparc64; mark
BROKEN on that platform.
changes which combine and simplify the post-install handling of target
libraries and GCJ include files and my 2003-12-14 change which simplifies
handling of .info files from the lang/gcc33 port.
are searched automatically by the compiler by using --with-libiconv-prefix.
W/o --with-libiconv-prefix, 'configure' finds the lib, but not the header.
During the make, neither will be found; a lot of inconsistency here...
* Deal with GCC's configurary's brokenness WRT --with-libiconv-prefix due
not actually passing the found header path to CFLAGS in any way.
least) two FreeBSD-related problems I had reported against the previous
snapshot.
Make some final adjustments to track changes in directory layout between
GCC 3.3 and 3.4, make some simplifications, and remove the BROKEN tag.
Import significant simplifications of the post-install handling of
GCJ include files from the gcc33 port. Use the new INFO= facility.
The port is still (marked) broken, but should essentially work out
of the box once the remaining upstream bugs have been fixed.
There is no bounds-checking patch for GCC 3.4 yet, extended printf format
checking for FreeBSD has not been ported yet, and the port is BROKEN due
to weird libjava build failures which occur if and only if building from
within the FreeBSD ports system.
