Re: Moved ports not being handled
On Wed, 29 Oct 2014, Warren Block wrote: Recently, portmaster kept wanting to upgrade these three ports: graphics/libcdr01 graphics/libfreehand print/libmspub01 It succeeded in rebuilding them every time, but always saw them as needing to be upgraded. Checking the output showed this: === The graphics/libcdr port moved to graphics/libcdr01 === Reason: Replaced by newer version === The graphics/libfreehand00 port moved to graphics/libfreehand === Reason: Replaced by newer version === The print/libmspub port moved to print/libmspub01 === Reason: Replaced by newer version The old versions were still installed, so each time an upgrade was performed with portmaster, it saw the old version and reinstalled the new version. After realizing this, it was easy enough to just pkg delete the old versions. Is an entry in UPDATING needed for these, or should portmaster handle them automatically? Forum thread: http://forums.freebsd.org/threads/graphics-libfreehand00-and-print-libmspub-not-updating-correctly.48703/ Seeing this again with textproc/libmwaw. The new version is installed, but the old version remains. ___ 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: Moved ports not being handled
Hi! Recently, portmaster kept wanting to upgrade these three ports: graphics/libcdr01 graphics/libfreehand print/libmspub01 Seeing this again with textproc/libmwaw. The new version is installed, but the old version remains. I've seen similar issues. This is my solution: If you delete the old version, then no further upgrade will be triggered. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Sat, 1 Nov 2014 00:07:23 +0100
Tijl Coosemans wrote:
On Fri, 31 Oct 2014 19:56:21 +0100 Baptiste Daroussin
b...@freebsd.org wrote:
Hi all,
tijl@ spotted an interesting point, distinfo and pkg-descr files
files convenient are taking a lot of space for free, we can
reduce the size of the while ports tree by a factor 2 by simply
merging them into one of the other files (Makefile and/or
pkg-plist) from my testing it really devides significantly the size
of the tree.
Problem is how to merge them if we want to.
What we do not want to loose:
- Easyness of parsing distinfo
- Easyness to get informations about the description
I think it's worth remembering that this saves an amount of storage
that can be had for around 1 penny/cent. The threshold for this being
more trouble than it's worth is pretty low.
so far I have not been able to figure out a user friendly way
Ideas I got so far only concerns pkg-descr:
Adding an entry in the Makefile for the WWW:
WWW= bla
or an entry in the plist: @www http...
for the description the Makefile is not suitable as multi line
entry in Makefiles are painful
Maybe a new keyword:
@descr EOD
mydesc
in
multiline
EOD
which could easily be added to the plist parser in pkg. But I'm do
not find that very friendly in particular for make(1) to extract
the data.
Concerning the distinfo I have no idea.
so this mail is a call of ideas :), if nothing nice ideas is found
we will just do nothing here :)
For distinfo I was thinking about something like this in the Makefile:
DIST_FILES= FOO BAR
FOO_FILE= foo-1.0
FOO_SITES=http://www.example.com/foo/
FOO_SIZE= 12345
FOO_SHA256= 0123456789abcdef.
BAR_FILE= bar-2.0
BAR_SITES=http://www.example.com/bar/
BAR_SIZE= 54321
BAR_SHA256= .fedcba9876543210
If bsd.port.mk then contained this:
DIST_FILES?= DIST
DIST_FILE?=
${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}
Then for ports with a single distfile named after PORTNAME (the large
majority), the above would reduce to:
DIST_SITES= http://www.example.com/foo/
DIST_SIZE=12345
DIST_SHA256= 0123456789abcdef.
Also, if BAR_SITES is the same as FOO_SITES you can use somthing like
BAR_SITES=${FOO_SITES} of course.
distviper and portsclean -D access all the distinfo files in the tree.
They could be heavily slowed if that information had to be got through
make targets.
___
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: Reducing the size of the ports tree (brainstorm v2)
How about using SQLite to store this metadata? Jos ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Sun, 2 Nov 2014 18:16:23 + RW rwmailli...@googlemail.com wrote: On Sat, 1 Nov 2014 00:07:23 +0100 Tijl Coosemans wrote: On Fri, 31 Oct 2014 19:56:21 +0100 Baptiste Daroussin b...@freebsd.org wrote: tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description I think it's worth remembering that this saves an amount of storage that can be had for around 1 penny/cent. The threshold for this being more trouble than it's worth is pretty low. The reason I looked into this is because many subversion operations are slow on the ports tree. For me it's about saving time there and not so much about saving disk space. ___ 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/tex-web2c kpathsea/paths.h not found
Erich Dollansky erichsfreebsdl...@alogt.com wrote in 20141102112717.69653...@x220.alogt.com: er Hi, er er when I try to compile tex-web2c, I will get this: er er configure: You requested to build `web2c' using an installed er `kpathsea' version, configure: which requires to locate the er kpathsea/paths.h header file. configure: error: Sorry, not found er under any of: /usr/local/include * === Script configure failed er unexpectedly. Please report the problem to h...@freebsd.org [maintainer] er and attach the er /usr/home/PORTS/work/usr/ports/devel/tex-web2c/work/texlive-20140525-source/texk/web2c/config.log er including the output of the failure of your make command. Also, it er might be a good idea to provide an overview of all packages installed er on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** er Error code 1 er er Stop. er make: stopped in /usr/ports/devel/tex-web2c er [X220]...devel/tex-web2c (root) er er I hope it is a simple as the file kpathsea/paths.h does not exist at all. Do you have tex-kpathsea package on your box? tex-web2c depends on it and your box should have it, but the error indicates that it does not exist. -- Hiroki pgptzMLU1CCZr.pgp Description: PGP signature
Re: Moved ports not being handled
On Sun, 2 Nov 2014, Kurt Jaeger wrote: Recently, portmaster kept wanting to upgrade these three ports: graphics/libcdr01 graphics/libfreehand print/libmspub01 Seeing this again with textproc/libmwaw. The new version is installed, but the old version remains. I've seen similar issues. This is my solution: If you delete the old version, then no further upgrade will be triggered. Yes, but is this a regression in portmaster, or should those ports be mentioned in UPDATING? ___ 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
SSP now default for ports/packages, ssp/new_xorg repository EOL
Ports and Package users, Ports now have SSP enabled by default. The package repository will now build SSP by default as well. SSP is Stack Smashing Protection and can be read about at https://en.wikipedia.org/wiki/Buffer_overflow_protection. This only applies to the head (/latest) packages, not the Quarterly branch packages. This applies to the ports checkout that portsnap uses. WITHOUT_SSP can be defined in make.conf to not use this feature. SSP will be used to build ports (with -fstack-protector) on all amd64 releases and i386 releases which are 10.0 or newer. The ssp repository and new_xorg repositories will no longer be updated after 11/15 as they are no longer needed as both are default for ports now. Please update your repository configurations to now only track the /latest repository. This is the default from /etc/pkg/FreeBSD.conf. Remove any overrides from /usr/local/etc/pkg/repos/ for the ssp or new_xorg repositories. Regards, Bryan Drewery on behalf of portmgr ___ 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
powerpc64 vs. Mesa-10.3.2: .libs/libmesa.a(builtin_functions.o)(.text+???): sibling call optimization to `_???' (various) does not allow automatic multiple TOCs
Context: powerpc64/GENERIC64 variant. I list the details at the end of this note, including for svnlite info /usr/ports but it is recently svnlite update'd. graphics/dri complained a lot about automatic multiple TOCs and reported needing to recompile with -minimal-toc or -fno-optimize-sibling-calls or to declare such things extern in work/Mesa-10.3.2/src/mesa/drivers/dri/ : CXXLDmesa_dri_drivers.la /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x18e0): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x195c): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern ... (It is a long list of these.) /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x175b0): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x17600): sibling call optimization to `_ZN11ir_function13add_signatureEP21ir_function_signature' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN11ir_function13add_signatureEP21ir_function_signature' extern /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x26c14): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern /usr/bin/ld: final link failed: Bad value Makefile:632: recipe for target 'mesa_dri_drivers.la' failed gmake[7]: *** [mesa_dri_drivers.la] Error 1 gmake[7]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/drivers/dri' Makefile:718: recipe for target 'all-recursive' failed gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/drivers/dri' Makefile:3967: recipe for target 'all-recursive' failed gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa' Makefile:1401: recipe for target 'all' failed gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa' Makefile:518: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src' Makefile:585: recipe for target 'all-recursive' failed gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2' === Compilation failed unexpectedly. Context details: root@FBSDG5M1:~/fbsd_rebuild_materials # uname -a FreeBSD FBSDG5M1 10.1-RC4 FreeBSD 10.1-RC4 #101 r273955M: Sat Nov 1 19:50:42 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 powerpc root@FBSDG5M1:~/fbsd_rebuild_materials # svnlite info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 273955 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 273874 Last Changed Date: 2014-10-30 15:21:12 -0700 (Thu, 30 Oct 2014) root@FBSDG5M1:~/fbsd_rebuild_materials # svnlite info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 372060 Node Kind: directory Schedule: normal Last Changed Author: madpilot Last Changed Rev: 372060 Last Changed Date: 2014-11-02 01:44:01 -0800 (Sun, 02 Nov 2014) root@FBSDG5M1:~/fbsd_rebuild_materials # svnlite status /usr/src/sys M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/powerpc/conf/GENERIC64 M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/ofw/ofwcall64.S /usr/src/sys/powerpc/conf/GENERIC64 root@FBSDG5M1:~/fbsd_rebuild_materials # svnlite diff /usr/src/sys/powerpc/conf/GENERIC64 Index: /usr/src/sys/powerpc/conf/GENERIC64 === --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 273955) +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy) @@ -28,7 +28,7 @@ # Platform support optionsPOWERMAC#NewWorld Apple PowerMacs -optionsPS3
Re: www/dansguardian revival?
On Fri, 31 Oct 2014 16:55:47 -0700 Nick Rogers ncrog...@gmail.com wrote
On Tue, Oct 21, 2014 at 6:29 PM, Chris H bsd-li...@bsdforge.com wrote:
On Tue, 21 Oct 2014 09:39:30 +0200 Marko Cupać marko.cu...@mimar.rs
wrote
On Mon, 20 Oct 2014 17:47:19 -0700
Chris H bsd-li...@bsdforge.com wrote:
Unless theirs any objection. I'll take it. I'll open a pr(1)
with a shar(1) ready, in about an hour.
--Chris
Nice to hear that dansguardian will be back in ports. I also used it
for years in combination with www/squid33 without problem. I was
compiling it from ports, and the trick was to compile squid33 first,
and dansguardian only after, as dansguardian would only check existence
of /use/local/bin/squid, and if it was already there, no matter which
version, it would happily compile, install and work.
Right. But there's ${STAGE} to deal with, as well. I may
make sqid34 the DEPENDS (I'm still testing).
I'm also working with the -devel version, and will likely
convert it to the (un)devel version, as there is less user
overhead involved -- RESTRICTED/COPYRIGHT/LICENSE/{...}
Should be able to post a complete version, sometime
tomorrow.
Hey Chris. Any luck getting your new dansguardian port to work? I can't
find a PR for it. Just wondering if theres anything I can do to help test
or if it would be worth my while to just submit a PR with the last-known
www/dansguardian for the time being. Thanks.
-Nick
Sorry for the delay, and thank you for your generous offer, Nick.
There were some issues with www/squid(34), and decided to wait
to see if they would be addressed soonish. I see that there was
a [partial] resolution just submitted. I'll see if they made it
into the ports tree. If so, I'll see where things are with
regard to their (e|a)ffect on www/dansguardian. If there's still
issues, I'll take you up on your generous offer. :)
FWIW I run my dev box on 11 (CURRENT).
Thanks, again.
--Chris
--Chris
--
Marko Cupać
https://www.mimar.rs
___
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-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-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-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: SSP now default for ports/packages, ssp/new_xorg repository EOL
On 2014-11-02 21:01, Bryan Drewery wrote: Ports and Package users, Ports now have SSP enabled by default. The package repository will now build SSP by default as well. SSP is Stack Smashing Protection and can be read about at https://en.wikipedia.org/wiki/Buffer_overflow_protection. This only applies to the head (/latest) packages, not the Quarterly branch packages. This applies to the ports checkout that portsnap uses. WITHOUT_SSP can be defined in make.conf to not use this feature. SSP will be used to build ports (with -fstack-protector) on all amd64 releases and i386 releases which are 10.0 or newer. The ssp repository and new_xorg repositories will no longer be updated after 11/15 as they are no longer needed as both are default for ports now. Please update your repository configurations to now only track the /latest repository. This is the default from /etc/pkg/FreeBSD.conf. Remove any overrides from /usr/local/etc/pkg/repos/ for the ssp or new_xorg repositories. Regards, Bryan Drewery on behalf of portmgr Hi Bryan, thats good notes, but how about users tracking ssp and changing the repo or upgrading to 10.1 if released? I suspect packages will be replaced during 10.1 upgrade with NON_SSP packages since the tree was tagged already yesterday by babt. -- 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: RE: reducing the size of the ports tree
On Sat, 1 Nov 2014 03:32:16 -0700 Jeffrey Bouquet via freebsd-ports freebsd-ports@freebsd.org wrote Not initially welcoming this new effort... explanation and other PKG problems taking precedence... I've a few scripts which use the smaller files, and have used them extensively in pipes. Syntax within the Makefile would make those counterintuitive.I would wonder also if it would break port infrastructure like the Mk and Tools and make search and portsearch (etc -- ports )... essentially breaking more things than would be solved. Indeed, I've many ideas for MORE small files for people crafting shell scripts that would be of more use down the road, and incorporated someday into additional port tools, portmasters, portupgrades, etc... So as far as this particular suggestion, maybe if someone wants it bad enough one should build a prototype and test locally several years with many ports and upgrades to determine what it breaks... and how to write new tools. But I conjecture that effort would be better spent with PR backlogs, fixing pkg2ng (which fails here on one machine ) etc... and making pkg more robust... (complete recovery if the database is hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc And the documentation. Many many more examples of everyday usage over the course of a year and UPDATING scenarious would be appreciated... and also streamlining pkg so it works better on low power machines with many ports installed. Including less segfaults... As an aside, I am now on a machine which never had the problem before, after a failed pkg2ng conversion, A... pkg install -f nettle wants to install csound! what file is telling it that? The database ??? ... and seven others I had just deinstalled B... make install ( proceeds with Child process terminated abnomally... segmentation fault) before the install. Not known if anything was running beforehand. Not problems with the install. But it keeps occuring... What process? Something in the background wanting that nettle csound dependency? Pkg working before the make command? Part of the make command infrastructure now more buggy? Thankfully that machine is not the primary one here, and all the programs installed still work on it as far as I know. But its registration data is not exact and pkg-devel as installed on it could be debugged more... as well as pkg2ng retested to work on v9 more precisely... It failed three times to convert that machine. (not installed unless desinstalling direct from the port, so could not upgrade.. or pkg info the port) I feel inclined to add a me too here. If nothing else, the proposal seems to violate POLA (not unlike pkg(8) did). Mind you, I _do_ recognize the advantages that pkg(8) brought. But [as yet] am not convinced it was (quite) time to make it _replace_ pkg(7). That said, and more to the point of this thread. I too believe it will introduce many issues for the toolsets users have built, and maintained against the current ports structure. As mentioned already; it will also _break_ many tools/utilities already available in the ports tree now. What to do then? Abandon/remove them? The requirement for sqlite3(1) that pkg(8) introduced was a poor decision IMHO. It introduces a single-point-of-failure that is generally considered bad practice for critical software. If something goes wrong with the database, you're up a creek, even with a backup. The introduction also broke many toolchains previously built against the largely text-based record keeping of pkg(7). Imagine if the DNS only required a single NS. What happens if that NS becomes unreachable? So it is for the sqlite3(1) requirement. What if you're an average user? You will likely have little knowledge of SQL syntax, and it will not be very helpful to them, if they need information about their ports install(s), or to manipulate things. While I've probably commented beyond the initial scope of this threads [intended] context. I think the other points I've made, also speak to the reasons I don't feel further modifications of the ports infrastructure would be welcomed, or advantageous. In this way, or at this time. Thank you for all your time, and consideration. --Chris ___ 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-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: powerpc64 vs. Mesa-10.3.2: .libs/libmesa.a(builtin_functions.o)(.text+???): sibling call optimization to `_???' (various) does not allow automatic multiple TOCs
On 2-11-2014 21:09, Mark Millard wrote: Context: powerpc64/GENERIC64 variant. I list the details at the end of this note, including for svnlite info /usr/ports but it is recently svnlite update'd. graphics/dri complained a lot about automatic multiple TOCs and reported needing to recompile with -minimal-toc or -fno-optimize-sibling-calls or to declare such things extern in work/Mesa-10.3.2/src/mesa/drivers/dri/ : CXXLDmesa_dri_drivers.la /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x18e0): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x195c): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern ... (It is a long list of these.) /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x175b0): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x17600): sibling call optimization to `_ZN11ir_function13add_signatureEP21ir_function_signature' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN11ir_function13add_signatureEP21ir_function_signature' extern /usr/bin/ld: ../../.libs/libmesa.a(builtin_functions.o)(.text+0x26c14): sibling call optimization to `_ZN9exec_nodenwEmPv' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_ZN9exec_nodenwEmPv' extern /usr/bin/ld: final link failed: Bad value Makefile:632: recipe for target 'mesa_dri_drivers.la' failed gmake[7]: *** [mesa_dri_drivers.la] Error 1 gmake[7]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/drivers/dri' Makefile:718: recipe for target 'all-recursive' failed gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/drivers/dri' Makefile:3967: recipe for target 'all-recursive' failed gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa' Makefile:1401: recipe for target 'all' failed gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa' Makefile:518: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2/src' Makefile:585: recipe for target 'all-recursive' failed gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.3.2' === Compilation failed unexpectedly. Can you try the following patch? We have the same fix in webkit-gtk3, so this might work for you. https://people.freebsd.org/~kwm/mesa-powerpc64.diff -Koop ___ 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: powerpc64 vs. Mesa-10.3.2: .libs/libmesa.a(builtin_functions.o)(.text+???): sibling call optimization to `_???' (various) does not allow automatic multiple TOCs
Thanks much. It may be a while before I get back to try this: I'm trying to build a powerpc64/GENERIC64 11.0 kernel variant for an experiment for someone and the PowerMac is busy doing that right now. === Mark Millard markmi at dsl-only.net On Nov 2, 2014, at 3:38 PM, Koop Mast kwm at rainbow-runner.nl wrote: Can you try the following patch? We have the same fix in webkit-gtk3, so this might work for you. https://people.freebsd.org/~kwm/mesa-powerpc64.diff -Koop ___ 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
audio/jack: Wrong file names
Hi, I am in the process of rebuilding all of my ports. When I try to rebuild /usr/ports/audio/jack, I run into a problem. This is the error message I have got: === Registering installation for jackit-0.124.1 pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_e.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_i.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_j.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_m.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_o.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_p.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_t.html): No such file or directory pkg-static: lstat(/usr/home/PORTS/work/usr/ports/audio/jack/work/stage/usr/local/share/jack-audio-connection-kit/reference/html/globals_w.html): No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/audio/jack But I have these files: [X220]...reference/html (root) ll gl* -rw-r--r-- 1 root wheel 3.6K Nov 3 07:37 globals.html -rw-r--r-- 1 root wheel 3.6K Nov 3 07:37 globals_0x65.html -rw-r--r-- 1 root wheel 3.7K Nov 3 07:37 globals_0x69.html -rw-r--r-- 1 root wheel44K Nov 3 07:37 globals_0x6a.html -rw-r--r-- 1 root wheel 3.6K Nov 3 07:37 globals_0x6d.html -rw-r--r-- 1 root wheel 3.6K Nov 3 07:37 globals_0x6f.html -rw-r--r-- 1 root wheel 4.1K Nov 3 07:37 globals_0x70.html -rw-r--r-- 1 root wheel 3.6K Nov 3 07:37 globals_0x74.html -rw-r--r-- 1 root wheel 3.6K Nov 3 07:37 globals_0x77.html -rw-r--r-- 1 root wheel 4.0K Nov 3 07:37 globals_defs.html -rw-r--r-- 1 root wheel 3.9K Nov 3 07:37 globals_enum.html -rw-r--r-- 1 root wheel11K Nov 3 07:37 globals_eval.html -rw-r--r-- 1 root wheel28K Nov 3 07:37 globals_func.html -rw-r--r-- 1 root wheel 7.8K Nov 3 07:37 globals_type.html -rw-r--r-- 1 root wheel 3.9K Nov 3 07:37 globals_vars.html Are the file names wrongly generated? Erich ___ 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
why is 'make' installing?
Issue, help appreciated. Missed day two of MeetBSD sorry alot going on today. Day one was great. I'm updating a port and noticed that 'make' is actually calling install in my program Makefile. seems strange. It's not registering the port as installed but the compiled binary is going into /usr/local/bin ie: ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make === License GPLv2 accepted by the user === Found saved configuration for dcraw-m-9.22 === dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dcraw-m-9.22 for building === Extracting for dcraw-m-9.22 = SHA256 Checksum OK for dcraw-m-9.22.tar.gz. === Patching for dcraw-m-9.22 === dcraw-m-9.22 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-m-9.22 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-m-9.22 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so - found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) === Configuring for dcraw-m-9.22 === Building for dcraw-m-9.22 === Staging for dcraw-m-9.22 === Generating temporary packing list install -m 0755 -g wheel -o root dcraw-m /usr/local/bin Compressing man pages (compress-man) Running Q/A tests (stage-qa) ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m AFAIK a port 'make' should not actually call install in the Makefile. ? rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean make cc -O2 -pipe -Wall -Werror -I/usr/local/include `MagickWand-config --cflags --cppflags` -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib `MagickWand-config --ldflags --libs` -lm -llcms2 -ljpeg -o dcraw-m dcraw-m.c ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m hmmm why is 'make' on the port Makefile calling install? uname -a FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27 18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH amd64 Thank you, -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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 is make installing
I wonder if that has anything with the child process terminated abnrmally I saw when starting a make build in most any, or a number of, port(s) recently... on another v9 machine. ___ 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 is 'make' installing?
On Sun, 2 Nov 2014 08:35:33 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote Issue, help appreciated. Missed day two of MeetBSD sorry alot going on today. Day one was great. I'm updating a port and noticed that 'make' is actually calling install in my program Makefile. seems strange. It's not registering the port as installed but the compiled binary is going into /usr/local/bin ie: ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make === License GPLv2 accepted by the user === Found saved configuration for dcraw-m-9.22 === dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dcraw-m-9.22 for building === Extracting for dcraw-m-9.22 = SHA256 Checksum OK for dcraw-m-9.22.tar.gz. === Patching for dcraw-m-9.22 === dcraw-m-9.22 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-m-9.22 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-m-9.22 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so - found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) === Configuring for dcraw-m-9.22 === Building for dcraw-m-9.22 === Staging for dcraw-m-9.22 === Generating temporary packing list install -m 0755 -g wheel -o root dcraw-m /usr/local/bin Compressing man pages (compress-man) Running Q/A tests (stage-qa) ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m AFAIK a port 'make' should not actually call install in the Makefile. ? rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean make cc -O2 -pipe -Wall -Werror -I/usr/local/include 'MagickWand-config --cflags --cppflags' -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib 'MagickWand-config --ldflags --libs' -lm -llcms2 -ljpeg -o dcraw-m dcraw-m.c ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m hmmm why is 'make' on the port Makefile calling install? Because you asserted make install? make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin That's all I can gather from the limited output you provided. :) --Chris uname -a FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27 18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH amd64 Thank you, -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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-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: Reducing the size of the ports tree (brainstorm v2)
On 11/2/14, 10:50 AM, Tijl Coosemans wrote: On Sun, 2 Nov 2014 18:16:23 + RW rwmailli...@googlemail.com wrote: On Sat, 1 Nov 2014 00:07:23 +0100 Tijl Coosemans wrote: On Fri, 31 Oct 2014 19:56:21 +0100 Baptiste Daroussin b...@freebsd.org wrote: tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description I think it's worth remembering that this saves an amount of storage that can be had for around 1 penny/cent. The threshold for this being more trouble than it's worth is pretty low. The reason I looked into this is because many subversion operations are slow on the ports tree. For me it's about saving time there and not so much about saving disk space. Starting to think that we should think about making the ports into trees that are category based and then another directory for the .mk files. Subversion supports externals, git supports submodules. Maybe it's time to leverage those and have a top level project with svn externals or git submodules. -Alfred ___ 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 is 'make' installing?
On Sun, November 2, 2014 5:23 pm, Chris H wrote: On Sun, 2 Nov 2014 08:35:33 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote Issue, help appreciated. Missed day two of MeetBSD sorry alot going on today. Day one was great. I'm updating a port and noticed that 'make' is actually calling install in my program Makefile. seems strange. It's not registering the port as installed but the compiled binary is going into /usr/local/bin ie: ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make === License GPLv2 accepted by the user === Found saved configuration for dcraw-m-9.22 === dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dcraw-m-9.22 for building === Extracting for dcraw-m-9.22 = SHA256 Checksum OK for dcraw-m-9.22.tar.gz. === Patching for dcraw-m-9.22 === dcraw-m-9.22 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-m-9.22 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-m-9.22 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so - found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) === Configuring for dcraw-m-9.22 === Building for dcraw-m-9.22 === Staging for dcraw-m-9.22 === Generating temporary packing list install -m 0755 -g wheel -o root dcraw-m /usr/local/bin Compressing man pages (compress-man) Running Q/A tests (stage-qa) ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m AFAIK a port 'make' should not actually call install in the Makefile. ? rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean make cc -O2 -pipe -Wall -Werror -I/usr/local/include 'MagickWand-config --cflags --cppflags' -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib 'MagickWand-config --ldflags --libs' -lm -llcms2 -ljpeg -o dcraw-m dcraw-m.c ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m hmmm why is 'make' on the port Makefile calling install? Because you asserted make install? make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin That's all I can gather from the limited output you provided. :) --Chris uname -a FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27 18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH amd64 Thank you, -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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 no, i was showing that the program Makefile only installs when you explicitly do 'make install', but the port Makefile seems to be calling 'make install' for some reason. here's another port that is not mine, it is doing the same thing.. [1492] cd /usr/ports/graphics/dcraw [1493] make === dcraw-9.21 depends on file: /usr/local/sbin/pkg - found = dcraw-9.21.tar.xz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/sunpoet/dcraw-9.21.tar.xz dcraw-9.21.tar.xz 100% of 78 kB 206 kBps 00m01s === Fetching all distfiles required by dcraw-9.21 for building === Extracting for dcraw-9.21 = SHA256 Checksum OK for dcraw-9.21.tar.xz. === Patching for dcraw-9.21 === dcraw-9.21 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-9.21 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-9.21 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === Configuring for dcraw-9.21 === Building for dcraw-9.21 dcraw.c:1009:4: warning: add explicit braces to avoid dangling else [-Wdangling-else] else ip[col][c] = (ip[col-width][c] + ip[col+width][c] + 1) 1; ^ dcraw.c:9038:41: warning: data argument not used by format string [-Wformat-extra-args] _(Converting to %s colorspace...\n), name[output_color-1]); ^ dcraw.c:9708:44: warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int] write_ext = .pgm\0.ppm\0.ppm\0.pam + colors*5-5; ~^~ dcraw.c:9708:44: note: use array indexing to silence this warning write_ext = .pgm\0.ppm\0.ppm\0.pam + colors*5-5; ^ [ ] 3 warnings generated. === Staging for dcraw-9.21 === Generating temporary packing
Re: why is 'make' installing?
It's installing into the staing directory in order to create the binary package that actually gets installed. More the full install path. This is the STAGING work that went on this year. On Nov 2, 2014 7:02 PM, Waitman Gobble uzi...@da3m0n8t3r.com wrote: On Sun, November 2, 2014 5:23 pm, Chris H wrote: On Sun, 2 Nov 2014 08:35:33 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote Issue, help appreciated. Missed day two of MeetBSD sorry alot going on today. Day one was great. I'm updating a port and noticed that 'make' is actually calling install in my program Makefile. seems strange. It's not registering the port as installed but the compiled binary is going into /usr/local/bin ie: ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make === License GPLv2 accepted by the user === Found saved configuration for dcraw-m-9.22 === dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dcraw-m-9.22 for building === Extracting for dcraw-m-9.22 = SHA256 Checksum OK for dcraw-m-9.22.tar.gz. === Patching for dcraw-m-9.22 === dcraw-m-9.22 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-m-9.22 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-m-9.22 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so - found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) === Configuring for dcraw-m-9.22 === Building for dcraw-m-9.22 === Staging for dcraw-m-9.22 === Generating temporary packing list install -m 0755 -g wheel -o root dcraw-m /usr/local/bin Compressing man pages (compress-man) Running Q/A tests (stage-qa) ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m AFAIK a port 'make' should not actually call install in the Makefile. ? rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean make cc -O2 -pipe -Wall -Werror -I/usr/local/include 'MagickWand-config --cflags --cppflags' -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib 'MagickWand-config --ldflags --libs' -lm -llcms2 -ljpeg -o dcraw-m dcraw-m.c ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m hmmm why is 'make' on the port Makefile calling install? Because you asserted make install? make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin That's all I can gather from the limited output you provided. :) --Chris uname -a FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27 18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH amd64 Thank you, -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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 no, i was showing that the program Makefile only installs when you explicitly do 'make install', but the port Makefile seems to be calling 'make install' for some reason. here's another port that is not mine, it is doing the same thing.. [1492] cd /usr/ports/graphics/dcraw [1493] make === dcraw-9.21 depends on file: /usr/local/sbin/pkg - found = dcraw-9.21.tar.xz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/sunpoet/dcraw-9.21.tar.xz dcraw-9.21.tar.xz 100% of 78 kB 206 kBps 00m01s === Fetching all distfiles required by dcraw-9.21 for building === Extracting for dcraw-9.21 = SHA256 Checksum OK for dcraw-9.21.tar.xz. === Patching for dcraw-9.21 === dcraw-9.21 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-9.21 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-9.21 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === Configuring for dcraw-9.21 === Building for dcraw-9.21 dcraw.c:1009:4: warning: add explicit braces to avoid dangling else [-Wdangling-else] else ip[col][c] = (ip[col-width][c] + ip[col+width][c] + 1) 1; ^ dcraw.c:9038:41: warning: data argument not used by format string [-Wformat-extra-args] _(Converting to %s colorspace...\n), name[output_color-1]); ^ dcraw.c:9708:44: warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int] write_ext
Re: why is 'make' installing?
On Sun, November 2, 2014 7:20 pm, Freddie Cash wrote: It's installing into the staing directory in order to create the binary package that actually gets installed. More the full install path. This is the STAGING work that went on this year. On Nov 2, 2014 7:02 PM, Waitman Gobble uzi...@da3m0n8t3r.com wrote: On Sun, November 2, 2014 5:23 pm, Chris H wrote: On Sun, 2 Nov 2014 08:35:33 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote Issue, help appreciated. Missed day two of MeetBSD sorry alot going on today. Day one was great. I'm updating a port and noticed that 'make' is actually calling install in my program Makefile. seems strange. It's not registering the port as installed but the compiled binary is going into /usr/local/bin ie: ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make === License GPLv2 accepted by the user === Found saved configuration for dcraw-m-9.22 === dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dcraw-m-9.22 for building === Extracting for dcraw-m-9.22 = SHA256 Checksum OK for dcraw-m-9.22.tar.gz. === Patching for dcraw-m-9.22 === dcraw-m-9.22 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-m-9.22 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-m-9.22 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so - found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) === Configuring for dcraw-m-9.22 === Building for dcraw-m-9.22 === Staging for dcraw-m-9.22 === Generating temporary packing list install -m 0755 -g wheel -o root dcraw-m /usr/local/bin Compressing man pages (compress-man) Running Q/A tests (stage-qa) ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m AFAIK a port 'make' should not actually call install in the Makefile. ? rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean make cc -O2 -pipe -Wall -Werror -I/usr/local/include 'MagickWand-config --cflags --cppflags' -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib 'MagickWand-config --ldflags --libs' -lm -llcms2 -ljpeg -o dcraw-m dcraw-m.c ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m hmmm why is 'make' on the port Makefile calling install? Because you asserted make install? make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin That's all I can gather from the limited output you provided. :) --Chris uname -a FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27 18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH amd64 Thank you, -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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 no, i was showing that the program Makefile only installs when you explicitly do 'make install', but the port Makefile seems to be calling 'make install' for some reason. here's another port that is not mine, it is doing the same thing.. [1492] cd /usr/ports/graphics/dcraw [1493] make === dcraw-9.21 depends on file: /usr/local/sbin/pkg - found = dcraw-9.21.tar.xz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/sunpoet/dcraw-9.21.tar.xz dcraw-9.21.tar.xz 100% of 78 kB 206 kBps 00m01s === Fetching all distfiles required by dcraw-9.21 for building === Extracting for dcraw-9.21 = SHA256 Checksum OK for dcraw-9.21.tar.xz. === Patching for dcraw-9.21 === dcraw-9.21 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-9.21 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-9.21 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === Configuring for dcraw-9.21 === Building for dcraw-9.21 dcraw.c:1009:4: warning: add explicit braces to avoid dangling else [-Wdangling-else] else ip[col][c] = (ip[col-width][c] + ip[col+width][c] + 1) 1; ^ dcraw.c:9038:41: warning: data argument not used by format string [-Wformat-extra-args] _(Converting to %s colorspace...\n), name[output_color-1]); ^ dcraw.c:9708:44: warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int] write_ext = .pgm\0.ppm\0.ppm\0.pam + colors*5-5; ~^~ dcraw.c:9708:44: note: use array indexing to
Re: cannot find -legacy error building /usr/lib32 with FreeBSD 10.1-RC3
On Thu 2014-10-23 22:45:52 UTC+1100, andrew clarke (m...@ozzmosis.com) wrote: My intention was to build virtualbox-ose-additions-4.3.18 from ports... # uname -a FreeBSD vbox-freebsd10 10.1-RC3 FreeBSD 10.1-RC3 #0 r273437: Tue Oct 21 23:55:15 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 # cd /usr/ports/emulators/virtualbox-ose-additions # make Requires 32-bit libraries installed under /usr/lib32. Do: cd /usr/src; make build32 install32; ldconfig -v -m -R /usr/lib32 *** Error code 1 Stop. It turns out I just needed to download ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.1-RC3/lib32.txz untar it to / and then I could build the above port. Not sure why I didn't have lib32 already installed. I must've unchecked it during the initial 10.0 install for some reason. ___ 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
