List of ports that don't build perfectly (or at all) with gcc44

I notice on three boxes that icu4, and probably icu don't build without gcc44. Which brings up the the question why we are running three year old system software? I know some BSD gurus are on an anti-Stallman kick but their arguments elude me, while their fix is mostly vaporware. x(

UPDATE: Actually icu does build on virgin 8.0 systems. Then something protrudes in the filesystem that trips up subsequent icu builds. Updating the autoconf, autobuilds don't help. Nor does making the libraries consistent. Somehow the patches fail to work 100%. And yes gcc44 still makes a perfect icu4 build. Just weird....

UPDATE: I used the divide and conquer approach to nail down libidn-1.15 as the cause of breakage in devel/icu. Problem report submitted.
 
rossiya said:
I notice on three boxes that icu4, and probably icu don't build without gcc44. Which brings up the the question why we are running three year old system software? I know some BSD gurus are on an anti-Stallman kick but their arguments elude me, while their fix is mostly vaporware. x(

it has nothing to do with being "anti-stallman"

It's a question of license. It's the same reason you dont' see ZFS in linux.
 
Speaking of LibGL, mesa-demos needs the same fix.

Code:
LDFLAGS="${PTHREAD_LIBS} -L${LOCALBASE}/lib -Wl,-Bsymbolic"
 
john_doe said:
Code:
.for port in nmap rtorrent* boost-libs wesnoth-devel
. if ${.CURDIR:M*/${port}}
   CXX = g++43
. endif
.endfor
Hmm, wesnoth-1.8.3 and boost-1.43 compiles fine with g++45 here.
 
Some ports have to be built twice, so to say. Firefox is no exception.

Code:
/path/to/port# make
^C
# cd path/to/work_directory
#cd files && make (config)
<correct whatever errors>
#cd /path/to/port
#make install clean
Run make config and make depends whenever possible.
AS for GCC, I install a few versions. Port does a search and finds necessary version, all is good.
 
I don't understand your pseudo example. What ports you need to build twice? What error they give you on first try?

firefox builds fine here from the first try.
 
Not a pseudo example. I work with nonx86 hardware. It's necessary more often than not to enter the work directory.
 
sossego said:
Not a pseudo example.
I don't see error there. Only some arcane magic that you're performing.
sossego said:
I work with nonx86 hardware.
What one? powerpc?
sossego said:
It's necessary more often than not to enter the work directory.
And why it is? Unless you give me an example of error your sentence seem not more than gibberish to me.
 
fairy said:
I don't see error there. Only some arcane magic that you're performing.
http://en.wikipedia.org/wiki/Magic_(disambiguation) My apologies but I don't practice such, use such, or have read such.
fairy said:
What one? powerpc?
A smart fool researches. You've done well my son.
fairy said:
And why it is? Unless you give me an example of error your sentence seem not more than gibberish to me.
Use the same equipment and you wouldn't have to ask such. http://www.google.com/search?hl=en&...raigslist.org+$40&aq=f&aqi=&aql=&oq=&gs_rfai=
I'm sure that you can afford the $40 bucks for the machine.
There is also the option of stopping the make process to see if a subdirectory of work exists.
 
Gentlemen, are we done with the increasingly prickly exchange? I'll happily give you both a week off if it continues. Thank you.
 
Proof:

Code:
tima# uname -a
FreeBSD tima.tiza 9.0-20100418-SNAP FreeBSD 9.0-20100418-SNAP #0: Sun Apr 18 06:51:02 UTC 2010     root@dynode.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  powerpc
tima# pwd
/usr/ports/net/xprobe
tima# ls
Makefile	distinfo	files		pkg-descr	pkg-plist	work
tima# ls work
.extract_done.xprobe2._usr_local	xprobe2-0.3
.patch_done.xprobe2._usr_local
tima# ls work/xprobe2-0.3
AUTHORS		CREDITS		README		cfg-scripts	docs		src
CHANGELOG	INSTALL		TODO		configure	etc
COPYING		Makefile.in	acconfig.h	configure.in	libs-external
tima# cd  work/xprobe2-0.3
tima# ./configure --help
`configure' configures this package to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
  -V, --version           display version information and exit
  -q, --quiet, --silent   do not print `checking...' messages
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'
  -n, --no-create         do not create output files
      --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
			  [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
			  [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR           user executables [EPREFIX/bin]
  --sbindir=DIR          system admin executables [EPREFIX/sbin]
  --libexecdir=DIR       program executables [EPREFIX/libexec]
  --datadir=DIR          read-only architecture-independent data [PREFIX/share]
  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
  --libdir=DIR           object code libraries [EPREFIX/lib]
  --includedir=DIR       C header files [PREFIX/include]
  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
  --infodir=DIR          info documentation [PREFIX/info]
  --mandir=DIR           man documentation [PREFIX/man]

Program names:
  --program-prefix=PREFIX            prepend PREFIX to installed program names
  --program-suffix=SUFFIX            append SUFFIX to installed program names
  --program-transform-name=PROGRAM   run sed PROGRAM on installed program names

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]

Optional Features:
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
 --enable-debug       enable debugging )

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
 --with-libpcap-includes=DIR  libpcap include directory
 --with-libpcap-libraries=DIR  libpcap library directory
 --with-libusipp-includes=DIR  libusipp include directory
 --with-libusipp-libraries=DIR  libusipp library directory

Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  CPPFLAGS    C/C++ preprocessor flags, e.g. -I<include dir> if you have
              headers in a nonstandard directory <include dir>
  CXX         C++ compiler command
  CXXFLAGS    C++ compiler flags
  CXXCPP      C++ preprocessor

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

tima# ls src
Makefile.in		interface.h		scan_engine.h		xprobe.h
cmd_opts.cc		interface_con.cc	target.cc		xprobe_module.h
cmd_opts.h		interface_con.h		target.h		xprobe_module_hdlr.cc
config.h.in		log.cc			targets_list.cc		xprobe_module_hdlr.h
config_set.cc		log.h			targets_list.h		xprobe_module_param.cc
config_set.h		os_matrix.cc		xplib			xprobe_module_param.h
defines.h.in		os_matrix.h		xpmodules		xprobe_timeval.h
interface.cc		scan_engine.cc		xprobe.cc
tima# ls src/*
src/Makefile.in			src/interface_con.h		src/targets_list.h
src/cmd_opts.cc			src/log.cc			src/xprobe.cc
src/cmd_opts.h			src/log.h			src/xprobe.h
src/config.h.in			src/os_matrix.cc		src/xprobe_module.h
src/config_set.cc		src/os_matrix.h			src/xprobe_module_hdlr.cc
src/config_set.h		src/scan_engine.cc		src/xprobe_module_hdlr.h
src/defines.h.in		src/scan_engine.h		src/xprobe_module_param.cc
src/interface.cc		src/target.cc			src/xprobe_module_param.h
src/interface.h			src/target.h			src/xprobe_timeval.h
src/interface_con.cc		src/targets_list.cc

src/xplib:
Makefile.in		xp_get_interface.h	xp_get_src_addr.cc	xp_sha1.h
README			xp_get_ping_payload.cc	xp_get_src_addr.h	xplib.h
xp_get_iface_addr.cc	xp_get_ping_payload.h	xp_lib.cc
xp_get_iface_addr.h	xp_get_random_data.cc	xp_lib.h
xp_get_interface.cc	xp_get_random_data.h	xp_sha1.cc

src/xpmodules:
Makefile.in		modules_proto		static_modules.h
alive_probe		os_probe
tima#


Code:
timey# uname -a
FreeBSD timey.time 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
timey# ls
Makefile	distinfo	files		pkg-descr	pkg-plist	work
timey# ls work
.extract_done.xprobe2._usr_local	xprobe2-0.3
.patch_done.xprobe2._usr_local
timey# ls work/xprobe2-0.3
AUTHORS		CREDITS		README		cfg-scripts	docs		src
CHANGELOG	INSTALL		TODO		configure	etc
COPYING		Makefile.in	acconfig.h	configure.in	libs-external
timey# cd  work/xprobe2-0.3
timey# ls src
Makefile.in		interface.h		scan_engine.h		xprobe.h
cmd_opts.cc		interface_con.cc	target.cc		xprobe_module.h
cmd_opts.h		interface_con.h		target.h		xprobe_module_hdlr.cc
config.h.in		log.cc			targets_list.cc		xprobe_module_hdlr.h
config_set.cc		log.h			targets_list.h		xprobe_module_param.cc
config_set.h		os_matrix.cc		xplib			xprobe_module_param.h
defines.h.in		os_matrix.h		xpmodules		xprobe_timeval.h
interface.cc		scan_engine.cc		xprobe.cc
timey#


If anyone doubts the validity of these statements then you can do the following.
Go to any port and start building.
CTRL+C after the file begins to build.
List the contents.

Now, in each subdirectory, you can further configure the application(s) beyond what is listed with make config arguments.

I don't need to apologize because I'm not wrong.
 
Tried to run a diff(1) on your output and didn't see the difference. What it's a proof of?
sossego said:
in each subdirectory, you can further configure the application(s) beyond what is listed with make config arguments.
So? If you're dissatisfied with `make config' (e.g. doesn't have options you're interested with) then bug the maintainer. I fail to see any error nor smth specific or odd in powerpc case.

Besides, net/xprobe should be marked as MAKE_JOBS_UNSAFE or simple patch to fix it should be applied
Code:
--- Makefile.in~
+++ Makefile.in
@@ -43,8 +43,8 @@ SIG=md5sum -b
 
 
 all: 
-    cd libs-external/USI++/src; ${MAKE}
-    cd src; ${MAKE}
+    (cd libs-external/USI++/src; ${MAKE})
+    (cd src; ${MAKE})
 
 
 clean:
There are a few other things broken in that port, see ports/148451.
 
I run ./configure from the subdirectory of /usr/ports/$SECTION/$PORT/work/$PORTS_SOURCE/$FILES when possible and can usually see where the error occurs. At times, one can just edit the file.
 
sossego said:
I run ./configure from the subdirectory of /usr/ports/$SECTION/$PORT/work/$PORTS_SOURCE/$FILES when possible
If configure target fails you usually have WRKSRC/config.log around.$ less $(make -V WRKSRC)/config.log
sossego said:
At times, one can just edit the file.
The user is not supposed to descend into WRKSRC and touch any files by hand there. Any issue with building ports should be reported to respective maintainer or gnats.
 
I usually don't check for config logs; so, thanks for the tip. (No sarcasm.)
Being that compiling for ppc is a touch and go process, I need to find the exact error.
Example from earlier was firefox.
I had to change libxul to libxul-devel and firefox ot firefox-devel with patches.
I ran ./configure and make| gmake- depending on file- in $WORK/$SUBDIRECTORIES to see what would function.

Code:
/usr/ports/www/elinks/work/elinks-0.11.7/src/session/download.c:692: warning: warning: tempnam() possibly used unsafely; consider using mkstemp()
Just did this with gmake from the subdirectory. That was the error. Yesterday, replaced
with
and the build broke. I'm rerunning it now- new source- to see if the error only occurs in subdirectory.
 
I just reran the build with:
Code:
#cd work/$SOURCE/src
#gmake
#cd ..
#gmake
#cd ..
#ls (to see if I missed something)
# cd ..
(In /usr/ports/www/elinks$DIR)
# gmake
#make install clean
And.....
it worked.

1.) Normal make doesn't always work. See above.
2.) It is necessary at times to run ./configure from work. This is at times a processor "dependency" or "problem" if you will.
3.) Make or gmake may have to be ran from $SUBDIRECTORY to each higher directory to correct the build.
4.) It's a learning experience.
5.) It's just plain fun and enjoyable to do at times.
 
sossego said:
I had to change libxul to libxul-devel and firefox ot firefox-devel with patches.
libxul-devel is only available in svn-gecko repository. If you're hacking ports you'd get better responses on freebsd-ports@.
sossego said:
warning: tempnam() possibly used unsafely; consider using mkstemp()
Warnings shouldn't break build unless you have -Werror in CFLAGS. BTW, sometimes you can force build to be verbose by
$ make V=1
sossego said:
2.) It is necessary at times to run ./configure from work. This is at times a processor "dependency" or "problem" if you will.
Only when you're hacking port and even then should better be avoided. bsd.port.mk supplies a few not very noticeable environment variables and configure args by default to configure script. And dependencies usually can be inspected from a more human-readable configure.(ac|in).

Most of the time you can restart configure or build target by simply typing `make'. make(1) and gmake(1) is smart enough to not try to compile sources again.
 
After recent update graphics/mupdf installation ends with sed error.

(Who needs update which adds dependencies and breaks the build with newer compiler, eh?)
 
fairy said:
if you have relatively old machine that's broken by optimization.

Only If you consider fresh STABLE old and -march=native silly optimization.

Code:
===>  Patching for mupdf-0.6,1
sed: 1: "s/CC = .*/CC = /usr/loc ...": bad flag in substitute command: 'u'
*** Error code 1
 
The port overrides `-march=native' with `-march=k8'. Besides, on gcc45 -march=native implies -msse[12345] depending on actual support and -ftree-vectorize is enabled when you specify -O3. In short the port should not try to outsmart its user. I for one have following CFLAGS in make.conf
Code:
CPUTYPE ?= native # for -march=native
DEBUG_FLAGS ?= -ggdb
SSP_CFLAGS ?= -fstack-protector
LTO_CFLAGS ?= -flto -fuse-linker-plugin
OPTIMIZE ?= -O3
CFLAGS += ${OPTIMIZE} ${DEBUG_FLAGS} ${SSP_CFLAGS}

.for port in git xmp zsh emacs*
. if ${.CURDIR:M*/${port}}
CFLAGS += ${LTO_CFLAGS}
. endif
.endfor
and override cc within PATH so I can build 32bit ports on amd64 or use gcc45 by default. If something goes weird I can always override optimization to empty string from command line to check that it doesn't break build/runtime. Any optimization beyond `-march=native' + `-O3' usually give much headache, especially smth like lto or graphite.

That sed(1) error is because you use full path that contains slashes. Do you distrust you own PATH that much?
 
Thanks for hint with full path, it was in plain sight and couldn't see it :)

BTW, stack-protector is not safe to turn on everywhere, e.g. after I recompiled all ports with it, I couldn't build png anymore.
 
The problem was not with building png with stack-protector, but rebuilding it (and mksh as well) after all ports were compiled with stack-protector.

Cherry picking ports for stack-protection usually works, it was after full ports recompile I have been hit by corner cases stick I suppose, so I chose to stay with more tested configuration.
 
Back
Top