Re: www/apache22 2.2.22_8 broken on IPv4-only system
On Wed, 05 Sep 2012, 07:52 +0200, Olli Hauer wrote: Do you have IPv6 in the devel/apr1 port enabled? No. rwsrv08# make showconfig -C /usr/ports/devel/apr1 | grep IPV6 IPV6=off: IPv6 protocol support The apache buildfiles are checking if APR_HAVE_IPV6 is present in the apr.h file (only the case if APR was build with IPV6) rwsrv08# grep V6 /usr/local/include/apr-1/apr.h #define APR_HAVE_IPV6 0 Maybe I'm looking in the wrong place or maybe the detection is broken? -- John Marshall pgpzOQSvxh9u3.pgp Description: PGP signature
Re: www/apache22 2.2.22_8 broken on IPv4-only system
On 2012-09-05 08:03, John Marshall wrote:
On Wed, 05 Sep 2012, 07:52 +0200, Olli Hauer wrote:
Do you have IPv6 in the devel/apr1 port enabled?
No.
rwsrv08# make showconfig -C /usr/ports/devel/apr1 | grep IPV6
IPV6=off: IPv6 protocol support
The apache buildfiles are checking if APR_HAVE_IPV6 is present in the apr.h
file (only the case if APR was build with IPV6)
rwsrv08# grep V6 /usr/local/include/apr-1/apr.h
#define APR_HAVE_IPV6 0
Maybe I'm looking in the wrong place or maybe the detection is broken?
Can you test the following diff.
Index: Makefile.modules
===
--- Makefile.modules(revision 303680)
+++ Makefile.modules(working copy)
@@ -151,6 +151,7 @@
.else
CONFIGURE_ARGS+= --disable-v4-mapped
.endif
+CONFIGURE_ARGS+= --disable-ipv6
CONFIGURE_ARGS+= --with-mpm=${WITH_MPM}
___
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: www/apache22 2.2.22_8 broken on IPv4-only system
On Wed, 05 Sep 2012, 08:10 +0200, Olli Hauer wrote:
Can you test the following diff.
Index: Makefile.modules
===
--- Makefile.modules(revision 303680)
+++ Makefile.modules(working copy)
@@ -151,6 +151,7 @@
.else
CONFIGURE_ARGS+= --disable-v4-mapped
.endif
+CONFIGURE_ARGS+= --disable-ipv6
CONFIGURE_ARGS+= --with-mpm=${WITH_MPM}
No change. Same symptoms. That's actually one of the patches I tried
prior to my original post.
The previous version of Makefile.modules (r303550) doesn't include the
server_config.c patch if IPv6 is disabled. I think that's the
(conditional) behaviour we need restored. If I remove the file
files/patch-server__config.c, the port builds fine.
--
John Marshall
pgpBKhb2qFL53.pgp
Description: PGP signature
Re: www/apache22 2.2.22_8 broken on IPv4-only system
On 2012-09-05 08:27, John Marshall wrote:
On Wed, 05 Sep 2012, 08:10 +0200, Olli Hauer wrote:
Can you test the following diff.
Index: Makefile.modules
===
--- Makefile.modules(revision 303680)
+++ Makefile.modules(working copy)
@@ -151,6 +151,7 @@
.else
CONFIGURE_ARGS+= --disable-v4-mapped
.endif
+CONFIGURE_ARGS+= --disable-ipv6
CONFIGURE_ARGS+= --with-mpm=${WITH_MPM}
No change. Same symptoms. That's actually one of the patches I tried
prior to my original post.
The previous version of Makefile.modules (r303550) doesn't include the
server_config.c patch if IPv6 is disabled. I think that's the
(conditional) behaviour we need restored. If I remove the file
files/patch-server__config.c, the port builds fine.
Thanks for the report, I will rework the patch so it checks for
APR_HAVE_IPV6.
___
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: www/apache22 2.2.22_8 broken on IPv4-only system
On Wed, 05 Sep 2012, 08:34 +0200, olli hauer wrote: On 2012-09-05 08:27, John Marshall wrote: The previous version of Makefile.modules (r303550) doesn't include the server_config.c patch if IPv6 is disabled. I think that's the (conditional) behaviour we need restored. If I remove the file files/patch-server__config.c, the port builds fine. Thanks for the report, I will rework the patch so it checks for APR_HAVE_IPV6. Thank you Olli, and thank you for maintaining this port. -- John Marshall pgpRW3QC5oTsO.pgp Description: PGP signature
Re: www/apache22 2.2.22_8 broken on IPv4-only system
On 2012-09-05 08:37, John Marshall wrote: On Wed, 05 Sep 2012, 08:34 +0200, olli hauer wrote: On 2012-09-05 08:27, John Marshall wrote: The previous version of Makefile.modules (r303550) doesn't include the server_config.c patch if IPv6 is disabled. I think that's the (conditional) behaviour we need restored. If I remove the file files/patch-server__config.c, the port builds fine. Thanks for the report, I will rework the patch so it checks for APR_HAVE_IPV6. Please can you test the following patch ad replacement for the existing one and remove the --disable-ipv6 line again. http://people.freebsd.org/~ohauer/diffs/apache/patch-server__config.c ___ 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: www/apache22 2.2.22_8 broken on IPv4-only system
On Wed, 05 Sep 2012, 08:45 +0200, olli hauer wrote: Please can you test the following patch ad replacement for the existing one and remove the --disable-ipv6 line again. http://people.freebsd.org/~ohauer/diffs/apache/patch-server__config.c Thank you. Builds and runs on: - FreeBSD 9.1-RC1 amd64 - FreeBSD 8.3-RELEASE i386 -- John Marshall pgpJO9yf7qNmR.pgp Description: PGP signature
Re: www/apache22 2.2.22_8 broken on IPv4-only system
On 2012-09-05 09:05, John Marshall wrote: On Wed, 05 Sep 2012, 08:45 +0200, olli hauer wrote: Please can you test the following patch ad replacement for the existing one and remove the --disable-ipv6 line again. http://people.freebsd.org/~ohauer/diffs/apache/patch-server__config.c Thank you. Builds and runs on: - FreeBSD 9.1-RC1 amd64 - FreeBSD 8.3-RELEASE i386 Thank you! I will send the new patch as update to the upstream apache development. -- Regards, olli ___ 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: dialogwrapper in ports
On 9/4/2012 12:41 PM, Warren Block wrote: dialogwrapper has now been committed to Tools/scripts in /usr/ports. Further testing is requested. What is dialogwrapper? dialogwrapper is a wrapper script for dialog(1) that works around some bugs and takes advantage of new features to make ports options setting easier and better. On FreeBSD 9 and later, two major features are available: 1. Extended descriptions. If a description won't fit in the space available, a + is shown at the far right and the remainder is shown at the bottom of the screen. The easiest way to test this is to pick a port, edit one of the option descriptions to be very long, then run 'make config'. Hopefully this will eventually allow port maintainers to use longer and more meaningful descriptions. 2. Variable menu size. Options screens in windows larger than 80x24 show wider descriptions and more lines. Convenient example: with a tall window, do 'make config' in print/ghostscript9. On FreeBSD 8, dialog(1) does not have a needed feature, so extended descriptions are merely chopped off. This also helps to avoid a bug in the older version's display of descriptions that are too long. How do I use dialogwrapper? Update your copy of the ports tree, then add this line to /etc/make.conf : DIALOG=/usr/ports/Tools/scripts/dialogwrapper.sh Configure port options as usual. It should look and work the same as usual, but handle long descriptions and bigger windows as described above. Brian Drewery responded: I've set this in my make.conf and tried it out. It's really cool. Would be nice to see this get more testing and possibly be set as default. Bryan This whets my virtual appetite, I'd like to try. But does this avoid the problem of getting messed up with the dialog when generating a log file with script or make install clean | tee build.log ? I noticed on http://www.freshports.org/commits.php just a day ago, devel/cdialog and x11/xdialog. Maybe xdialog avoids this messing up when generating a log file, but can only be used after xorg is built and installed. Tom ___ 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
Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
Hello.
FreeBSD has fallen back far behind the standards of modern scientific
computing and I dsperately look for solutions having OpenCL support on
FreeBSD anyway.
I stumbled into this project recently:
FreeOCL at
http://code.google.com/p/freeocl/
or the sources located at
http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gzcan=2q=
For your convenience, please find my naive attempt of a port attached to
this email.
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP. Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
[...]
[ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o
In file included from
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istreamchar' to
'const bool'
const bool ok = in.get(c);
^~
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13:
warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL',
'HALF'... [-Wswitch]
switch(native-get_type_id())
^
1 warning and 1 error generated.
*** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1
[..]
I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that
fails with
[...]
-- Build files have been written to:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source
=== Building for freeocl-0.3.6
Scanning dependencies of target FreeOCL
[ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o
In file included from
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2:
error: 'u_int64_t' does not name a type
*** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1
[...]
I think patches are required.
More disturbing is the use of gcc-4.6 via
USE_GCC= 4.6+
The error is then a compalin about a missing include file
atomic_ops.h
which is located in the abandoned KSE facility of the kernel, so the
includes seem not to be installed anymore - but since I'm not involved
in the development, I can only guess and ask the people here.
Maybe some experienced freeBSD developers with the same need for OpenCl
is willing to pick up this and help a bit.
Well, as far as I see, the FreeOCL project of Roland Borchard is a
OpenCL library for CPU usage. As far as I can understand, if we on
FreeBSd could have a library libOpenCL as this is usually installed by
the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support
with their GPUs, this would fill a still painfull open gap in FreeBSD as
a scientific development platform.
There is still no suitable compiler for OpenCL out here for freeBSD, but
I have still the hope that LLVM can provide such a thing in the near future.
I cross post this posting also to performance in the hope finding some
people attracted and lurd into this subject.
Regards,
O. Hartmann
PORTNAME= freeocl
PORTVERSION=0.3.6
CATEGORIES= devel
MAINTAINER= po...@freebsd.org
COMMENT=FreeOCL - a free OpenCL implementation for CPU
#MASTER_SITES=
http://freeocl.googlecode.com/files/FreeOCL-0.3.6-src.tar.gz
MASTER_SITES= http://freeocl.googlecode.com/files/
DISTNAME= FreeOCL-${PORTVERSION}-src
WRKSRC= ${WRKDIR}/FreeOCL-${PORTVERSION}-Source
USE_CMAKE= YES
CMAKE_BUILD_TYPE= Release
USE_GCC=4.7+
#CXXFLAGS+= -stdlib=libc++
.include bsd.port.mk
signature.asc
Description: OpenPGP digital signature
Re: dialogwrapper in ports
On Wed, 5 Sep 2012, Thomas Mueller wrote: Configure port options as usual. It should look and work the same as usual, but handle long descriptions and bigger windows as described above. Brian Drewery responded: I've set this in my make.conf and tried it out. It's really cool. Would be nice to see this get more testing and possibly be set as default. Bryan This whets my virtual appetite, I'd like to try. But does this avoid the problem of getting messed up with the dialog when generating a log file with script or make install clean | tee build.log ? Probably not. I'm not sure if either dialog or dialogwrapper can do anything about what goes into a teed file. I noticed on http://www.freshports.org/commits.php just a day ago, devel/cdialog and x11/xdialog. Maybe xdialog avoids this messing up when generating a log file, but can only be used after xorg is built and installed. Either of these may be better than the dialog(1) in base. But one of the goals of dialogwrapper was to not need anything extra that would have to be installed from ports. ___ 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
FreeBSD Port: p5-DBD-Oracle-1.14_3
/usr/ports/databases/p5-DBD-Oracle was marked as broken five weeks
ago (as of this writing).
I commented out the broken directive in the Makefile and found that
it was indeed broken but I know I had made this port from source in
the past, and I recalled the error messages I was seeing today, and I
recalled (roughly) what it was I had done in the past to make the port
build and install.
I don't submit bug reports (and perhaps I should) but here is my poor
man's way of submitting my patch diffs for databases/p5-DBD-Oracle:
I have attached a text file of context diffs and included it here:
--- Oracle.c.orig 2012-09-05 11:59:43.0 -0400
+++ Oracle.c2012-09-05 12:12:04.0 -0400
@@ -1493,11 +1493,11 @@
XS_EUPXS(XS_DBD__Oracle__st_ora_execute_array); /* prototype to pass
-Wmissing-prototypes */
XS_EUPXS(XS_DBD__Oracle__st_ora_execute_array)
{
dVAR; dXSARGS;
if (items 4 || items 5)
- croak_xs_usage(cv, sth, tuples, exe_count, tuples_status,
cols=sv_undef);
+ croak_xs_usage(cv, sth, tuples, exe_count, tuples_status,
cols=PL_sv_undef);
{
SV *sth = ST(0)
;
SV *tuples = ST(1)
;
@@ -1510,11 +1510,11 @@
D_imp_sth(sth);
int retval;
#line 1513 Oracle.c
if (items 5)
- cols = sv_undef;
+ cols = PL_sv_undef;
else {
cols = ST(4)
;
}
#line 127 Oracle.xs
@@ -1547,11 +1547,11 @@
{
SV *sth = ST(0)
;
#line 147 Oracle.xs
D_imp_sth(sth);
-ST(0) = dbd_st_cancel(sth, imp_sth) ? sv_yes : sv_no;
+ST(0) = dbd_st_cancel(sth, imp_sth) ? PL_sv_yes : PL_sv_no;
#line 1554 Oracle.c
}
XSRETURN(1);
}
@@ -1569,11 +1569,11 @@
;
char * pwd = (char *)SvPV_nolen(ST(2))
;
#line 159 Oracle.xs
D_imp_dbh(dbh);
-ST(0) = ora_db_reauthenticate(dbh, imp_dbh, uid, pwd) ? sv_yes : sv_no;
+ST(0) = ora_db_reauthenticate(dbh, imp_dbh, uid, pwd) ? PL_sv_yes :
PL_sv_no;
#line 1576 Oracle.c
}
XSRETURN(1);
}
@@ -1621,19 +1621,19 @@
/* added by lab: */
/* LAB do something about length here? see above comment */
OCILobCharSetForm_log_stat( imp_dbh-envhp, imp_dbh-errhp, locator,
csform, status );
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobCharSetForm);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
return;
}
#ifdef OCI_ATTR_CHARSET_ID
/* Effectively only used so AL32UTF8 works properly */
OCILobCharSetId_log_stat( imp_dbh-envhp, imp_dbh-errhp, locator, csid,
status );
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobCharSetId);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
return;
}
#endif /* OCI_ATTR_CHARSET_ID */
/* if data is utf8 but charset isn't then switch to utf8 csid */
csid = (SvUTF8(data) !CS_IS_UTF8(csid)) ? utf8_csid :
CSFORM_IMPLIED_CSID(csform);
@@ -1643,14 +1643,14 @@
bufp, (ub4)data_len, OCI_ONE_PIECE,
NULL, NULL,
(ub2)0, csform , status);
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobWrite);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
}
else {
- ST(0) = sv_yes;
+ ST(0) = PL_sv_yes;
}
#line 1654 Oracle.c
}
XSRETURN(1);
}
@@ -1700,19 +1700,19 @@
/* added by lab: */
/* LAB do something about length here? see above comment */
OCILobCharSetForm_log_stat( imp_dbh-envhp, imp_dbh-errhp, locator,
csform, status );
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobCharSetForm);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
return;
}
#ifdef OCI_ATTR_CHARSET_ID
/* Effectively only used so AL32UTF8 works properly */
OCILobCharSetId_log_stat( imp_dbh-envhp, imp_dbh-errhp, locator, csid,
status );
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobCharSetId);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
return;
}
#endif /* OCI_ATTR_CHARSET_ID */
/* if data is utf8 but charset isn't then switch to utf8 csid */
csid = (SvUTF8(data) !CS_IS_UTF8(csid)) ? utf8_csid :
CSFORM_IMPLIED_CSID(csform);
@@ -1721,20 +1721,20 @@
amtp, bufp, (ub4)data_len, OCI_ONE_PIECE,
NULL, NULL,
csid, csform, status);
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobWriteAppend);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
}
else {
- ST(0) = sv_yes;
+ ST(0) = PL_sv_yes;
}
#else
OCILobGetLength_log_stat(imp_dbh-svchp, imp_dbh-errhp, locator, startp,
status);
if (status != OCI_SUCCESS) {
oci_error(dbh, imp_dbh-errhp, status, OCILobGetLength);
- ST(0) = sv_undef;
+ ST(0) = PL_sv_undef;
} else {
Apache lockf state after implementing SSL
Hi, I've just setup a new dev server using FreeBSD 9 p3. FreeBSD ibanez.x.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Apache/2.2.22 (FreeBSD) PHP/5.3.16 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8q DAV/2 I've created some self-signed certificates and implemented SSL with Apache. When I am looking at top, I see that I have 1 httpd in the select state, and the rest of my httpd child processes are in the lockf state. Before implementing SSL, none of my httpd processes were ever in the lockf state when idle. Are these processes in the lockf state because of the use of SSL with apache? I'll apologize ahead of time as I read the digests, but never really post and this is really bugging me. If this has been answered or someone has a link just let me know. Please let me know if I need to include more information. Also, apologies if I haven't formatted anything correctly. Thank you in advance. Kind Regards, Billy Markert Partner Markert Consulting, LLC Billy AT markertconsulting DOT com ___ 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
Strange behavior in mc-light
Hello all.
Since there's no maintainer for mc-light, I'd like to ask help from all of
you :)
I'm cross-compiling this port for arm, with such command:
env TARGET=arm TARGET_ARCH=armv6 TARGET_CPUARCH=armv6
CONFIGURE_HOST=arm-portbld-freebsd10.0
PATH=/usr/obj/arm.armv6/usr/src/tmp/usr/bin:${PATH}
STRIP_CMD=/usr/obj/arm.armv6/usr/src/tmp/usr/bin/strip make
WITHOUT_CHECKS=yes -C /usr/ports/misc/mc-light build
This device seems have no MMAP, so I had to comment out these lines:
view.c:643
// if (intr_flag) {
// view-partial = 1;
// view-s.st_size = 0;
// }
Looks like not complete patching for me :)
But that's not the point.
Main problem that I got failing at one place (repeated with manual gmake
call)
# env TARGET=arm TARGET_ARCH=armv6 TARGET_CPUARCH=armv6
CONFIGURE_HOST=arm-portbld-freebsd10.0
PATH=/usr/obj/arm.armv6/usr/src/tmp/usr/bin:${PATH}
STRIP_CMD=/usr/obj/arm.armv6/usr/src/tmp/usr/bin/strip gmake man2hlp
cc -O2 -pipe -fno-strict-aliasing -I..
-I/wrkdirs/usr/ports/misc/mc-light/work/mc-4.1.40-pre9/intl -I./../vfs
-I./.. -I./../slang -I.. -DBINDIR=\/usr/local/bin/\
-DLIBDIR=\/usr/local/share/mc/\
-DLOCALEDIR=\/usr/local/share/locale/\ -DWANT_PARSE -DREGEX_MALLOC
armv6 man2hlp.c -o man2hlp
cc: armv6: No such file or directory
gmake: *** [man2hlp] Error 1
Seems that somehow after -DREGEX_MALLOC there for some reason inserted
$TARGET_ARCH (rechecked with different values, like arm67 )
Is there any sense in this?
Thanks.
--
Regards,
Alexander Yerenkow
___
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: Strange behavior in mc-light
Alexander Yerenkow yeren...@gmail.com wrote:
# env TARGET=arm TARGET_ARCH=armv6 TARGET_CPUARCH=armv6
CONFIGURE_HOST=arm-portbld-freebsd10.0
PATH=/usr/obj/arm.armv6/usr/src/tmp/usr/bin:${PATH}
STRIP_CMD=/usr/obj/arm.armv6/usr/src/tmp/usr/bin/strip gmake man2hlp
cc -O2 -pipe -fno-strict-aliasing -I..
-I/wrkdirs/usr/ports/misc/mc-light/work/mc-4.1.40-pre9/intl -I./../vfs
-I./.. -I./../slang -I.. -DBINDIR=\/usr/local/bin/\
-DLIBDIR=\/usr/local/share/mc/\
-DLOCALEDIR=\/usr/local/share/locale/\ -DWANT_PARSE -DREGEX_MALLOC
armv6 man2hlp.c -o man2hlp
cc: armv6: No such file or directory
gmake: *** [man2hlp] Error 1
Seems that somehow after -DREGEX_MALLOC there for some reason inserted
$TARGET_ARCH (rechecked with different values, like arm67 )
Is there any sense in this?
It appears that man2hlp above is built using an implicit builtin
rule, which for GNU make involves TARGET_ARCH for some reason.
I don't know where this is documented, but take a look:
$ strings /usr/local/bin/gmake | grep TARGET_ARCH | grep CC
$(CC) $(LDFLAGS) $(TARGET_ARCH)
$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
So your best bet is to add a rule for man2hlp to src/Makefile.in;
I'm attaching a patch agains the port to this effect; it seems
to work for me.
diff -ruN mc-light.orig/files/patch-src_Makefile.in
mc-light/files/patch-src_Makefile.in
--- mc-light.orig/files/patch-src_Makefile.in 2012-09-05 23:40:25.0
+0300
+++ mc-light/files/patch-src_Makefile.in2012-09-05 23:47:01.0
+0300
@@ -3,7 +3,17 @@
--- src/Makefile.in.orig Wed Aug 18 23:32:30 2004
+++ src/Makefile.inFri Sep 3 14:47:25 2004
-@@ -135,7 +135,7 @@
+@@ -76,6 +76,9 @@
+ mc: $(OBJS) @LIBVFS@ @LIBSLANG@ @LIBEDIT_A@
+ $(CC) $(LDFLAGS) -o $@ $(OBJS) -L../vfs -L../slang -L../edit $(OURLIBS)
$(LIBS)
+
++man2hlp: man2hlp.c
++ $(CC) $(CFLAGS) $(LDFLAGS) -o $@ man2hlp.c
++
+ mfmt: mfmt.o
+ $(CC) $(LDFLAGS) mfmt.o -o mfmt
+
+@@ -135,7 +138,7 @@
install: mc mfmt @saver@
$(INSTALL_PROGRAM) mc $(DESTDIR)$(bindir)/$(binprefix)mc
$(INSTALL_PROGRAM) mcmfmt $(DESTDIR)$(bindir)/$(binprefix)mcmfmt
___
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
Update for x11/libfm failed
I get this when trying to update checking for valac... /usr/local/bin/valac checking /usr/local/bin/valac is at least version 0.13.0... no configure: error: Vala 0.13.0 not found. === Script configure failed unexpectedly. Please report the problem to kmo...@freebsd.org [maintainer] and attach the /usr/ports/x11/libfm/work/libfm-1.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/sbin/pkg_info -Ea). *** Error code 1 Stop in /usr/ports/x11/libfm. === make failed for x11/libfm === Aborting update === Update for x11/libfm failed === Aborting update On my system vala-0.12.1 is installed. Can't find any later version. Help Please Thanks /Leslie This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by libfm configure 1.0, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --prefix=/usr/local --sysconfdir=/usr/local/etc --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd8.2 ## - ## ## Platform. ## ## - ## hostname = bljbsd01.no-ip.org uname -m = amd64 uname -r = 8.2-RELEASE-p9 uname -s = FreeBSD uname -v = FreeBSD 8.2-RELEASE-p9 #0: Mon Jun 11 23:00:11 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC /usr/bin/uname -p = amd64 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /bin PATH: /usr/bin PATH: /sbin PATH: /usr/sbin PATH: /usr/local/bin PATH: /usr/local/sbin ## --- ## ## Core tests. ## ## --- ## configure:2479: checking for a BSD-compatible install configure:2547: result: /usr/bin/install -c -o root -g wheel configure:2558: checking whether build environment is sane configure:2608: result: yes configure:2749: checking for a thread-safe mkdir -p configure:2788: result: /usr/local/bin/gmkdir -p configure:2801: checking for gawk configure:2817: found /usr/local/bin/gawk configure:2828: result: gawk configure:2839: checking whether gmake sets $(MAKE) configure:2861: result: yes configure:2994: checking for gcc configure:3021: result: cc configure:3250: checking for C compiler version configure:3259: cc --version 5 cc (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3270: $? = 0 configure:3259: cc -v 5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] configure:3270: $? = 0 configure:3259: cc -V 5 cc: '-V' option must have argument configure:3270: $? = 1 configure:3259: cc -qversion 5 cc: unrecognized option '-qversion' cc: No input files specified configure:3270: $? = 1 configure:3290: checking whether the C compiler works configure:3312: cc -O2 -pipe -fno-strict-aliasing -I/usr/local/include -L/usr/local/lib conftest.c 5 configure:3316: $? = 0 configure:3364: result: yes configure:3367: checking for C compiler default output file name configure:3369: result: a.out configure:3375: checking for suffix of executables configure:3382: cc -o conftest -O2 -pipe -fno-strict-aliasing -I/usr/local/include -L/usr/local/lib conftest.c 5 configure:3386: $? = 0 configure:3408: result: configure:3430: checking whether we are cross compiling configure:3438: cc -o conftest -O2 -pipe -fno-strict-aliasing -I/usr/local/include -L/usr/local/lib conftest.c 5 configure:3442: $? = 0 configure:3449: ./conftest configure:3453: $? = 0 configure:3468: result: no configure:3473: checking for suffix of object files configure:3495: cc -c -O2 -pipe -fno-strict-aliasing -I/usr/local/include conftest.c 5 configure:3499: $? = 0 configure:3520: result: o configure:3524: checking whether we are using the GNU C compiler configure:3543: cc -c -O2 -pipe -fno-strict-aliasing -I/usr/local/include conftest.c 5 configure:3543: $? = 0 configure:3552: result: yes configure:3561: checking whether cc accepts -g configure:3581: cc -c -g -I/usr/local/include conftest.c 5 configure:3581: $? = 0 configure:3622: result: yes configure:3639: checking for cc option to accept ISO C89 configure:3702: cc -c -O2 -pipe -fno-strict-aliasing -I/usr/local/include conftest.c 5 configure:3702: $? = 0 configure:3715: result: none needed configure:3746: checking for style of include used by gmake configure:3774: result: GNU configure:3800: checking dependency style of cc configure:3911: result: gcc3 configure:3930: checking whether cc understands -c and -o
Automatic Port
Hi all, I'm considering a -devel port which checks out from our upline's VCS repo, also generating a dynamic plist. I'm sure this is possible. Are there any examples of this? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ 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
