Re: USE_GCC doesn't set rpath
On Thu, Jan 23, 2014 at 9:56 PM, John Marino freebsd.cont...@marino.stwrote: On 1/23/2014 20:53, Bernhard Fröhlich wrote: Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com: On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri No it can't right now and this is why we need a ports compiler. Right now we are hiding this problems by the fact that we are able to build 95% percent of the tree with clang and everyone is happy. We add dozens of patches to compile with clang or add this rpath workarounds to even more ports just because nobody wants to acknowledge that this is shit and won't work properly unless really everything is build with one compiler. The rpath stuff is only a workaround that works in a few cases but it doesn't work in all cases. You will still see very hard to diagnose runtime crashes. While I basically agree with this sentiment, is not it just ports that use C++ that are affected? Could not this be narrowed down to We need a single compiler for ports that use C++ ? No. Everything that uses language- or feature-support library are affected. I'm, for example, unable to use OpenMP higher than 2.5 even if compiler is gcc-4.8, which is openmp-3.x capable). But, from my point of view, the problem is not a compiler nor rpath. rpath is unneeded indeed, and library indeed may be only one (under /lib). The real problem is that this is ancient library, not the most recent one. They are especially designed to be backward compatible and have the same so-number for a reason. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: opencv update
On Thu, Dec 5, 2013 at 12:07 AM, Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org wrote: Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org writes: Ajtim lum...@gmail.com writes: I did what is in /usr/ports/UPDATING and looks like I am in trouble now. My system is FreeBSD 10.0-BETA4 (amd64): === FreeBSD 10 autotools fix applied to /usr/ports/multimedia/ffmpeg0/work/ffmpeg-0.7.16/configure ERROR: opencv-core not found Looks like ffmpeg0's opencv support should now depend on graphics/opencv rather than graphics/opencv-core. I'm testing this theory now... No, that's not right. There's some configure-script editing in the port that I hadn't noticed. It's probably a minor fix, but in the meantime turning off ffmpeg0's option for opencv should get you around it. I didn't verified it yet, but my assumption that it's combination of wrong order of linker parameters and --as-needed option. Libraries placed before object file, which uses them (wrong order), so at the time of theirs occurrence they are unneeded and therefore skipped. Similar problem would to occur independently of --as-needed if static libraries would be used instead of dynamic, or linker occur more strict/conservative. PS. @Mark: cvCreateImageHeader, symbol, which test program tries to find in opencv-core.so library, exists there and exported indeed. It absent in the output of plain nm (or 'nm -a' in your case) just because library is heavy stripped (removed anything unneeded for ld.so). If use 'nm -D', you will see that symbol. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: opencv update
On Thu, Dec 5, 2013 at 3:38 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Thu, Dec 5, 2013 at 12:07 AM, Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org wrote: Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org writes: Ajtim lum...@gmail.com writes: I did what is in /usr/ports/UPDATING and looks like I am in trouble now. My system is FreeBSD 10.0-BETA4 (amd64): === FreeBSD 10 autotools fix applied to /usr/ports/multimedia/ffmpeg0/work/ffmpeg-0.7.16/configure ERROR: opencv-core not found Looks like ffmpeg0's opencv support should now depend on graphics/opencv rather than graphics/opencv-core. I'm testing this theory now... No, that's not right. There's some configure-script editing in the port that I hadn't noticed. It's probably a minor fix, but in the meantime turning off ffmpeg0's option for opencv should get you around it. I didn't verified it yet, but my assumption that it's combination of wrong order of linker parameters and --as-needed option. Libraries placed before object file, which uses them (wrong order), so at the time of theirs occurrence they are unneeded and therefore skipped. Similar problem would to occur independently of --as-needed if static libraries would be used instead of dynamic, or linker occur more strict/conservative. PS. @Mark: cvCreateImageHeader, symbol, which test program tries to find in opencv-core.so library, exists there and exported indeed. It absent in the output of plain nm (or 'nm -a' in your case) just because library is heavy stripped (removed anything unneeded for ld.so). If use 'nm -D', you will see that symbol. ffmpeg0 configure script considers as libraries only parameters started with '-l'. See check_ld() functions. But opencv-core pkg-config file (opencv-core.pc) reports absolute library filenames /usr/local/lib/libopencv_core.so /usr/local/lib/libopencv_imgproc.so instead of expected by configure -L/usr/local/lib -lopencv_core -lopencv_imgproc. It results in treating these .so as CFLAGS with all consequences. There are two ways to cure: 1. patch ffmpeg0 configure to detect libraries without -l 2. patch opencv-core .pc file to report libraries as -lname instead of /path/to/libname.so Patch for ffmpeg0 configure is attached. -- Andrew W. Nosenko andrew.w.nose...@gmail.com patch-configure-check-ld Description: Binary data ___ 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: CC, CPP etc vs CONFIGURE_ENV
On Wed, Nov 6, 2013 at 6:51 PM, Charles Swiger cswi...@mac.com wrote:
On Nov 6, 2013, at 7:25 AM, Andriy Gapon a...@freebsd.org wrote:
Setting $CC and such worked with older ./configure which didn't implement
$CONFIGURE_ENV.
It also plays more nicely with things which roll their own ./configure as a
shim
that isn't actually GNU autoconf.
Apologies, you seem to think that CONFIGURE_ENV is an environment variable of
its own. But, as far as I can see, it is not. It is a make variable with a
value that expands to FOO=BAR VAR=VAL ... and those FOO, VAR, etc are the
environment variables that are to be set in configure's environment:
${SETENV} ... ${CONFIGURE_ENV} ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
Yes, setup via ports/bsd.options.mk and such (aka configure.mk on some other
platforms).
So, either I didn't understand what you said or what you said is not
relevant.
That's fair enough-- I don't always manage to be both comprehensible and
relevant. :-)
I seemed to recall that sufficiently modern configure's would look into
$CONFIGURE_ENV if you set it via:
export ${CONFIGURE_ENV}; ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
...instead. But I don't see signs of that in GNU autoconf, so that might be
a non-standard thing.
After variable substitution by make, it will become something like
export VAR1=FOO VAR2=BAR; ./configure
and then executed by shell. So, from configure script point of view,
it is the same environment variables.
--
Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: [HEADSUP] Staging, packaging and more
On Tue, Oct 8, 2013 at 11:47 AM, Baptiste Daroussin b...@freebsd.org wrote: Concerning the fact that you need a couple of new packages to be able to actually build something out github or whatever, this is a developer problem and doing pkg install gtk2-dev is not complicated at all. While installing gtk2-dev is not hard indeed, finding the name of package, which you need (gtk2-dev in your example) may be much harder. Just an example: Ubuntu has a package for curl (commandline utility): http://packages.ubuntu.com/precise/curl curl (commandline utility) is a thin wrapper around libcurl, libcurl is registered as a dependency. No problems yet, just go through hypelink. http://packages.ubuntu.com/precise/libcurl3 Now, can you say me, what package should I install for obtain headers, .pc, debug symbols and other developer-related stuff for that libcurl? Not some libcurl, but that specific libcurl, which was fetched as dependency of the curl (commandline utility)? It just a fear. My fear. Fear that possibility to create packages/subpackages may lead to creating them randomly, and these randomly created packages/subpackages may lead to the same problems as demonstrated above. And, seems, I'm not alone in that. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: ports 10-CURRENT
On Wed, Jun 19, 2013 at 4:32 PM, Cy Schubert cy.schub...@komquats.com wrote: You don't understand. devel/imake is a fine piece of software but people do not want to install more software than they have to. net/vnc comes with it's own integrated Xserver. Using this logic we should integrate x11-servers/xorg into it too. Neither makes sense. The only reason to use devel/imake is if net/vnc _installs_ its own imake, which it does not. There's no reason to install more software just to build other software if we don't need it. It's extra baggage. If follow this logic, net/vnc should to bundle it's own C compiler then... -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: [HEADSUP] dialog4ports does not popup anymore only for global options
On Fri, Jun 7, 2013 at 9:58 PM, Chris Rees utis...@gmail.com wrote: On 7 June 2013 18:49, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Fri, Jun 7, 2013 at 8:15 PM, Chris Rees utis...@gmail.com wrote: I can see your point when talking about DOCS, but for NLS it's insanity *for general use*. Give me an example of where NLS non-globals are appropriate and I'll shut up. The GIMP in Russian locale. GNU Make in any non-English locale. I guess you mean the translations are bad? Your guess is wrong. For some reason you are treating NLS as black and white thing. Either completely enable, or completely disable. Please, just belive that there are lot of grays in between. But I'm completely against: 1. Poor or confusing translations (when easiest way to understand something is to try to back-translate to English, or in some pathological cases, start application in the English locale and match UI elements by position); 2. Translations of tools, which are intended to or used to interact with other tools, as opposed to the end users (GNU make, GCC, Git, GnuPG are perfect examples) 3. Ports which do not provide the easy enough and consistent way to disable NLS. Just because it deprives me a way to workaround cases #1 and #2. And the #3 is the reason, why I stand up in this thread. I don't bother about popping-up dialogs. After all, I'm not in a business of rebuilding the whole ports tree from scratch every day. And even a machine will wait my answer the whole night -- not a problem. Summary time required to build plus wasted time is negligible in comparison to time spent in using application. Therefore, the first thing, which I optimize, is a comfort of using application, and other things are going only after that. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: [HEADSUP] dialog4ports does not popup anymore only for global options
On Fri, Jun 7, 2013 at 8:15 PM, Chris Rees utis...@gmail.com wrote: I can see your point when talking about DOCS, but for NLS it's insanity *for general use*. Give me an example of where NLS non-globals are appropriate and I'll shut up. The GIMP in Russian locale. GNU Make in any non-English locale. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: [HEADSUP] dialog4ports does not popup anymore only for global options
On Fri, Jun 7, 2013 at 8:23 PM, Michael Gmelin free...@grem.de wrote: I was mostly talking about DOCS, I (poorly) chose NLS as an additional example to show how multiple groups could work. Usually NLS is a true global option. NLS is global option only for people with en_* locale, who, therefore, just don't see the pain produced by it. DOCS are just a space on HDD. But localized names of image filters, tools Co in GIMP -- it's just a barrier to use books and other knowledge sources. And I don't say just about stupid eye-blow errors in translations, when results of automatic merge went in the release and the wild without even fast looking through by the someone, who has that language as native. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer ger...@pfeifer.com wrote: On Mon, 25 Mar 2013, Anton Shterenlikht wrote: I've now run ia64 with the above change for over 2 weeks, mostly rebuilding ports, etc. I didn't see any issues with gcc47. So, from my very limited testing, gcc47 can be made default. Thanks for the feedback, Anton! To really make that switch globally, we'll need more extensive testing, a full ports builds run, since there is a chance that some port you are not using may be broken, and I hope to get this done in the coming weeks. From my expiriense, devel/glib20 cannot be compiled with gcc47. Isn't it built with the system default compiler: configure:3954: checking for C compiler version configure:3963: cc --version 5 cc (GCC) 4.2.1 20070831 patched [FreeBSD] I think we are only talking about updating lang/gcc to 4.7. By default -- yes, it is going to build with base gcc. But topic and, therefore, my reaction was about overriding compiler to be lang/gcc* from ports and whether there are ports, which fail in that case. At least, as I understand it. Now, why overriding the compiler for Glib seems important to me and why I tried to do that: Since commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58 Author: Ryan Lortie de...@desrt.ca Date: Tue Oct 18 16:21:50 2011 -0400 gatomic: introduce G_ATOMIC_LOCK_FREE glib atomics implementation depends on gcc predefined macro __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base gcc-4.2 and on Clang (all version, at least at that time). As consequence, we have a mutex-based implementation of atomics. Building Glib using more modern GCC (e.g. gcc-4.7) would help, but gnome-libtool hack prevents us from that. See also: Thread atomic ops broken on mac/xcode https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html Gnome bugzilla #682818: atomic ops broken on mac/xcode https://bugzilla.gnome.org/show_bug.cgi?id=682818 LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_ http://llvm.org/bugs/show_bug.cgi?id=11174 -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger mezz.free...@gmail.com wrote: On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer ger...@pfeifer.com wrote: On Mon, 25 Mar 2013, Anton Shterenlikht wrote: I've now run ia64 with the above change for over 2 weeks, mostly rebuilding ports, etc. I didn't see any issues with gcc47. So, from my very limited testing, gcc47 can be made default. Thanks for the feedback, Anton! To really make that switch globally, we'll need more extensive testing, a full ports builds run, since there is a chance that some port you are not using may be broken, and I hope to get this done in the coming weeks. From my expiriense, devel/glib20 cannot be compiled with gcc47. Isn't it built with the system default compiler: configure:3954: checking for C compiler version configure:3963: cc --version 5 cc (GCC) 4.2.1 20070831 patched [FreeBSD] I think we are only talking about updating lang/gcc to 4.7. By default -- yes, it is going to build with base gcc. But topic and, therefore, my reaction was about overriding compiler to be lang/gcc* from ports and whether there are ports, which fail in that case. At least, as I understand it. Now, why overriding the compiler for Glib seems important to me and why I tried to do that: Since commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58 Author: Ryan Lortie de...@desrt.ca Date: Tue Oct 18 16:21:50 2011 -0400 gatomic: introduce G_ATOMIC_LOCK_FREE glib atomics implementation depends on gcc predefined macro __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base gcc-4.2 and on Clang (all version, at least at that time). As consequence, we have a mutex-based implementation of atomics. Building Glib using more modern GCC (e.g. gcc-4.7) would help, but gnome-libtool hack prevents us from that. Did you install all ports with GCC 4.7? If you install libtool with foo compiler then install other ports with bar compiler will be broken. You have to reinstall libtool with the bar compiler to make other ports with bar compiler works. No, I should not do that (of course if assume that port machinery doesn't interfere with configure results by discarding part of them). libtool script is a _generated_ thing when used with autoconf. 'configure' does some checks (including how to execute linker depending on used languages) and generates the current libtool sript using these results. This generated script has nothing with /usr/local/bin/libtool. Moreover, the system-wide libtool has no business there, not used and may be completely absent until you want regenerate and replace all package-supplied tools by your copy by something like 'autoreconf -f'. As you can see, under proper workflow, there no dependency, which version of compiler was installed or used on the time of /usr/local/bin/libtool generation. All knowledge about currently used language, compiler, linker abelities and so on are gatchered by configure and written into local package-specific libtool script (in contrast to the global /usr/local/bin/libtool). The only one problem that ports machinery decides to trow out these results and use own copy, which know nothing about actual package preferences, needs, nor used language. See also: Thread atomic ops broken on mac/xcode https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html Gnome bugzilla #682818: atomic ops broken on mac/xcode https://bugzilla.gnome.org/show_bug.cgi?id=682818 LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_ http://llvm.org/bugs/show_bug.cgi?id=11174 -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
me...@bristol.ac.uk wrote:
From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013
On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer
ger...@pfeifer.com wrote:
On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
I've now run ia64 with the above change for over 2 weeks,
mostly rebuilding ports, etc.
I didn't see any issues with gcc47.
So, from my very limited testing,
gcc47 can be made default.
Thanks for the feedback, Anton! To really make that switch
globally, we'll need more extensive testing, a full ports builds
run, since there is a chance that some port you are not using
may
be broken, and I hope to get this done in the coming weeks.
From my expiriense, devel/glib20 cannot be compiled with gcc47.
Isn't it built with the system default compiler:
configure:3954: checking for C compiler version
configure:3963: cc --version 5
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
I think we are only talking about updating lang/gcc to 4.7.
By default -- yes, it is going to build with base gcc. But topic and,
therefore, my reaction was about overriding compiler to be lang/gcc*
from ports and whether there are ports, which fail in that case. At
least, as I understand it.
Now, why overriding the compiler for Glib seems important to me and
why I tried to do that:
Since
commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
Author: Ryan Lortie de...@desrt.ca
Date: Tue Oct 18 16:21:50 2011 -0400
gatomic: introduce G_ATOMIC_LOCK_FREE
glib atomics implementation depends on gcc predefined macro
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
gcc-4.2 and on Clang (all version, at least at that time).
As consequence, we have a mutex-based implementation of atomics.
Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
gnome-libtool hack prevents us from that.
Did you install all ports with GCC 4.7? If you install libtool with
foo compiler then install other ports with bar compiler will be
broken. You have to reinstall libtool with the bar compiler to make
other ports with bar compiler works.
No, I should not do that (of course if assume that port machinery
doesn't interfere with configure results by discarding part of them).
You need to try it. You can't assume anything.
I don't assume. I just know it. Know from everyday usage.
It's well known that if
you change the CC/CXX then you have to reinstall libtool. Although, I
don't know if it's still true for present libtool, but it was problem
with libtool15 at last time when I checked. The libtool15 will storage
the CC, CXX and other stuff as default of what you used it on
libtool15. (ie: Run 'libtool --config')
My knowledge based on 2.x series. At the times of 1.x, the base
compiler was modern enough for mitigate the need to redefine
compilers.
The gnome-libtool was copied from ${LOCALBASE}/bin/libtool (libtool
port) then patch the bug of shared library version in gnome-libtool.
It also changed the configure to look at gnome-libtool. Nothing more
and nothing less. You can look at Mk/bsd.gnome.mk by search for
ltverhack.
I know it and knew at the time of writting.
I don't know or don't understand why these hacks are needed, and, if
they are really needed, then why they maintained separatelly instead
of be pushed to the upstream and become part of libtool
out-of-the-box.
If, for some reason, libtool upstream cannot be conviced, or just at
the transition stage, why patch the ${LOCALBASE}/bin/libtool? Why
don't patch the local libtool generated by package's configure and
which contains all configure-gatchered variables properly filled (at
least for those packages, which use fresh enough libtool version)? Or
why don't patch the devel/libtool (if need) for install the patched
ltmain.sh (if need) and then force package to re-grab
autotools/libtool related things and regenerate the configure script?
libtool script is a _generated_ thing when used with autoconf.
'configure' does some checks (including how to execute linker
depending on used languages) and generates the current libtool sript
using these results. This generated script has nothing with
/usr/local/bin/libtool. Moreover, the system-wide libtool has no
business there, not used and may be completely absent until you want
regenerate and replace all package-supplied tools by your copy by
something like 'autoreconf -f'.
As you can see, under proper workflow, there no dependency, which
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer ger...@pfeifer.com wrote: On Mon, 25 Mar 2013, Anton Shterenlikht wrote: I've now run ia64 with the above change for over 2 weeks, mostly rebuilding ports, etc. I didn't see any issues with gcc47. So, from my very limited testing, gcc47 can be made default. Thanks for the feedback, Anton! To really make that switch globally, we'll need more extensive testing, a full ports builds run, since there is a chance that some port you are not using may be broken, and I hope to get this done in the coming weeks. From my expiriense, devel/glib20 cannot be compiled with gcc47. Reason, as I see it, the reality may be slightly different or more complex, but, I hope it will give a hint about direction: 1. glib'c configure checks whether -Bsymbolic-functions option is supported by linker (by passing it as -Wl,-Bsymbolic-functions through CC/CXX frontend) 2. Because gcc47 frontend calls /usr/local/lib/ld, which is fresh enough, the check passes as supported. 3. configure registers gcc47 as linker frontend, generates libtool script, and so on... 4. At the real link time the port machinery hijacks invocations to the generated libtool scrips and redirects them to the own gnome-libtool, which know nothing about configure results, and which uses hardcoded cc instead of requested gcc47 5. cc is /usr/bin/cc aka gcc-4.2 in my case. It uses /usr/bin/ld (from base) instead of /usr/local/bin/ld (from ports). 6. Base version lf ld is old enough and know nothing about -Bsymbolic-functions flag. 7. As consequence, build finishes with linker error. Again: The description above may be inaccurate or wrong in details. I didn't investigate the problem throughly. But it is how it looks like. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: update failed for security/nss-3.14.3
On Thu, Feb 21, 2013 at 11:38 AM, Alex Dupre a...@freebsd.org wrote: Florian Smeets wrote: Jan committed a patch that should work, is that an acceptable workaround for your use case (it pulls in a newer gcc)? Can you test it and report back? Yes, it works correctly, thanks. Sorry, but it doesn't work for my FreeBSD-8.0. The gcc-4.2 from base (under name 'cc') is used anyway with the same error cc1: error: unrecognized command line option -mssse3 as consequence. The build log snippet follows: cc -o FreeBSD8.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/intel-gcm-wrap.o -c -O2 -pipe -O2 -march=native -I/usr/local/include/nspr -L/usr/local/lib -B/usr/local/bin -fno-strict-aliasing -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../dist/FreeBSD8.0_OPT.OBJ/include -I../../dist/public/ -I../../dist/private/ -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -I../../../dist/FreeBSD8.0_OPT.OBJ/include -I../../../dist/public/ -I../../../dist/private/ -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\so.1\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_USE_64 -DNSS_X86_OR_X64 -DNSS_X64 -DNSS_BEVAND_ARCFOUR -DMPI_AMD64 -DMP_ASSEMBLY_MULTIPLY -DNSS_USE_COMBA -DMP_CHAR_STORE_SLOW -DMP_IS_LITTLE_ENDIAN -DUSE_HW_AES -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD8.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\so.1\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DNSS_USE_64 -DNSS_X86_OR_X64 -DNSS_X64 -DNSS_BEVAND_ARCFOUR -DMPI_AMD64 -DMP_ASSEMBLY_MULTIPLY -DNSS_USE_COMBA -DMP_CHAR_STORE_SLOW -DMP_IS_LITTLE_ENDIAN -DUSE_HW_AES -DMP_API_COMPATIBLE -I../../../../dist/FreeBSD8.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl -mssse3 intel-gcm-wrap.c cc1: error: unrecognized command line option -mssse3 gmake[3]: *** [FreeBSD8.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/intel-gcm-wrap.o] Error 1 -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: update failed for security/nss-3.14.3
On Fri, Feb 22, 2013 at 1:17 PM, Alex Dupre a...@freebsd.org wrote: Andrew W. Nosenko wrote: Jan committed a patch that should work, is that an acceptable workaround for your use case (it pulls in a newer gcc)? Can you test it and report back? Yes, it works correctly, thanks. Sorry, but it doesn't work for my FreeBSD-8.0. The gcc-4.2 from base (under name 'cc') is used anyway with the same error The patch was actually committed to the FreeBSD ports tree only recently (18 hours ago). Are you sure you have it? Sure. Ports tree was updated about 1.5 hours before writting that mail. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: reading epub files?
On Tue, Nov 13, 2012 at 10:16 PM, Robert Huff roberth...@rcn.com wrote: A quick grep of the ports index doesn't find any likely candidates. Does such a port exist? Firefox' EPUBReader extension -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: emacs23
On Sat, Sep 22, 2012 at 1:47 PM, Andrea Venturoli m...@netfence.it wrote: Hello. What are the plans for emacs23? It is marked as vulnerable now, but emacs24 is almost unusable (1)... bye Thanks av. (1) I'm mainly referring to gdb integration: in case anyone is interested, I can describe some of the problems. Did you asked about that in emacs development list (emacs-de...@gnu.org)? -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: pkg(ng)/portupgrade-devel: does not respect setting of USE_GCC= 4.6+
On Mon, Aug 20, 2012 at 10:39 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I'm pretty sure, that the last time I updated port math/fftw3 I wanted option OpenMP enabled so I declared USE_GCC=4.6+ in make.conf. Later, also working!, I excluded all these user definitions into an external file called ports.conf located in /usr/local/etc (I like this clean separation of OS and user messes ;-) ). Suddenly it doesn't work anymore. There were changes in several Mk files located in /usr/ports/Mk. Beware! Even if you will be able to force gcc-4.6 to be used and thus obtain OpenMP-3.1 at the compilation stage, the libgomp.so.1, which will be used at run-time, will be OpenMP-3.0 from the base gcc-4.2 (/usr/lib/libgomp.so.1 on my FreeBSD-8.0 system). Also, as a bonus, you may be exposed to ancient bugs from the gcc-4.2 openmp implementation. For me, personally, it is memory leak as described in http://gcc.gnu.org/ml/gcc/2009-05/msg00427.html Fixed in gcc-4.3, but gcc-4.3 never was nor will be in base. Thus... For obtain the proper openmp you will either limit yourself to openmp-3.0 from gcc-4.2 and workaround known bugs, or make a black magic dance for override and unsteal the libgomp (e.g. using libmap.conf) and have maintenance problem every time when gcc version changes (and, therefore, changes the directory name, where gcc libraries live). -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: MATE 'base' desktop is ready for anyone to test it.
On Wed, Aug 1, 2012 at 7:09 AM, Kevin Oberman kob6...@gmail.com wrote: Looks like MATE is gathering steam. I saw that Fedora is switching from Gnome3 to MATE Are you sure? Can you point me to announce, e-mail in mailing list or something like that? Not the messages like now MATE available for Fedora, but Fedora prefers MATE over Gnome3 or MATE is the default DE for Fedora replacing Gnome3, or something like that. Reason: Fedora is RedHat project. Gnome3 driven by RedHat people mostly. Therefore, Fedora switches from Gnome to MATE essencially would to mean RedHat switches has focus from Gnome to MATE that would to mean Gnome loses the major supporter and driving force. Therefore: please, point me to the source of your Fedora is switching from Gnome3 to MATE statement or be more accurate in citing and/or interpretation. MATE proposed to inclusion into Fedora 18 absolutelly not equal to MATE replaces Gnome3 in in Fedora 18 nor Fedora 18 switches from Gnome3 to MATE. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: clang, dbus, firefox+thunderbird
On Wed, Jun 20, 2012 at 11:54 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-06-19 19:14, Andrew W. Nosenko wrote: On Tue, Jun 19, 2012 at 6:16 PM, Boris Samorodov b...@passap.ru wrote: ... /usr/local/include/dbus-1.0/dbus/dbus-protocol.h:459:126: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] #define DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE !DOCTYPE node PUBLIC \DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER\\n\DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER\\n ... It's because of User defined literals (the new c++11 feature) and your clang++ is in c++11 (or gnu++11?) mode by default. Note, the version of clang in base defaults to gnu++98, *not* c++11 or gnu++11. Maybe this is added by the configure script, after detection of c++11 support? Another posibility: message about C++11 user defined literals is just a warning intended for forward compatibility, but promoted to error because of -Werror. But it's just a guess, I'm didn't tried to build firefox or thunderbird by self. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: clang, dbus, firefox+thunderbird
On Tue, Jun 19, 2012 at 6:16 PM, Boris Samorodov b...@passap.ru wrote: Hi List, I use clang compiled world (WITH_CLANG_IS_CC=YES and WITH_LIBCPLUSPLUS=YES at /etc/make.conf). The system is current: - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #16 r237055: Thu Jun 14 17:16:43 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - While updating to the latest firefox I get an error: - /usr/local/include/dbus-1.0/dbus/dbus-protocol.h:459:77: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] #define DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE !DOCTYPE node PUBLIC \DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER\\n\DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER\\n ^ /usr/local/include/dbus-1.0/dbus/dbus-protocol.h:459:126: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] #define DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE !DOCTYPE node PUBLIC \DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER\\n\DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER\\n ^ 2 errors generated. - OK, I did make config and deselect DBUS. Great, firefox compiles and installs (the latest one, 13.0.1). Then I try to upgrade thunderbird and get the same error. However there is no option DBUS to disable. What am I to do? Thanks! It's because of User defined literals (the new c++11 feature) and your clang++ is in c++11 (or gnu++11?) mode by default. As workaround, you may try either: downgrade to something like gnu++ 98 (-std=gnu++98), or edit dbus-protocol.h header for make it c++11 compatible. It's easy: just add spaces around DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER and DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER literals in the line 459 (just as compiler suggested). I.e. the line 459 #define DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE !DOCTYPE node PUBLIC \DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER\\n\DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER\\n should be written as #define DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE !DOCTYPE node PUBLIC \ DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER \\n\ DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER \\n -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: FreeBSD Port: mc-4.8.1.1
On Thu, Apr 19, 2012 at 20:05, freethread freethread...@gmail.com wrote: hi, I'm facing an issue with last mc version. After upgrading ports (from source with portmaster) the syntax highlight in mcedit no more works, well, it works, but... Explanation I made some customization in mc for fileext, syntax highlight and menus, some of them are documentend, some others are partially documented and some others are undocumented. The syntax highlight customization is partially documented, however that's what I've done on my system: The syntax highlight are composed by files with .syntax extention and a main 'Syntax' file that recognize file type (extentions + content) and redirect to the right .syntax file. 1.. I created a new directory where I copied that files (located in /usr/local/share/mc/syntax) in that new directory. 2.. In each home directory there is an '.mc' directory where mc place per user configuration files, so I found that copying the above files in $HOME/.mc/cedit directory you can customize the syntax highlight recognition and coloration, so what I've done (for each user) is to create symlinks to that files in 'cedit' directory, pointing at files copied in step 1. So, each user has the same customized syntax highlight. Now, it worked for years, but when updated mc to version 4.8.1.1, it show me a syntax error in Syntax file at line 41, that contain the following customization: 40 file .\*(csh|\\.(csh|cshrc|tcsh|tcshrc|login|logout))$ tcsh/csh\sScript ^#!\s\*/(.\*/|usr/bin/env\s)(tc|c)sh41 include csh.syntaxOk, I restored the original 'Syntax' file to replace the customized one, but it seems it has no effect, it display the same error and in the editor menu 'Options - Syntax Highlight...' it still display my customized additions (in the previous example 'tcsh/csh Script'), and it uses its own .syntax files in /usr/local/share/mc/syntax for all file types. I don't know if mc has a cache and where it is, in /tmp there is nothing to help. This is not a FreeBSD issue instead something changed in mc syntax highlight policy, anyhow, perhaps you know or heard about some changes, I use mcedit for small shell files, small perl and python scripts on FreeBSD server but the most of the time I works on Windows desktops (and access it with remote terminals), so I can revert mc to works as default and edit them in Windows. The latest mc from ports changed the paths to be more XDG complaint. Config files live now in ~/.config/mc/ (and, as consequence, ~/.config/mc/mcedit/ if you need mcedit-related ones). State-related files live in ~/.local/mc/ now. At the 1st run after update, the mc copies the old configs into new locations, which explains why your changes to the files inside ~/.mc/ had no effect and why you had a feeling like something cached somewhere. Also, at the 1st run (just after copying), mc shows message about new paths and what happened, and exits. But you can easy to miss it if your terminal emulator closes the window automatically after mc exit. FYI: I made many other customizations to mc but I don't know if they interfere with this issue, all of them have more than 2 years and always worked and they are the same from at least 1 year, anyway my system was installed from 'disk 1' in september 2010, fresh FreeBSD 9.0-BETA1 installation (it was an 8.2-RELEASE but I made a fresh install to test bsdinstall and have SU+J on UFS), upgraded to 9.0-RELEASE in january or frebuary with freebsd-update (binary), all ports are uptodate. FreeBSD alpha.xxx.xxx 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Fri Jan 20 07:29:38 CET 2012 r...@alpha.xxx.xxx:/usr/obj/usr/src/sys/ALPHA i386 Thanks in advance for your advices (if you have any) paul -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Building ports with gcc46
On Thu, Dec 15, 2011 at 02:05, b. f. bf1...@googlemail.com wrote:
If you are interested in applying them to a single port, use a test on
.CURDIR,
or, better yet, add the statement to any of the optional Makefiles that are
automatically included by bsd.port.mk and were intended for that purpose --
${MASTERDIR}/Makefile.local, for example.
Unfortunatelly, the Makefile.local included too late for have any
positive/intended effect (e.g. define port-specific WITH/WITHOUT knob,
modify CONFIGURE_ARGS,...) in many cases/ports. Therefore, advise to
use Makefile.local is unreliable. And we left in situation, where
make.conf is the only one reasonable working solution :-(
But yes, it should be properly conditionalized by .if/.endif
--
Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: binutils-2.22: ld and --copy-dt-needed-entries
On Tue, Dec 6, 2011 at 23:41, Andriy Gapon a...@freebsd.org wrote:
on 06/12/2011 23:24 Martin Matuska said the following:
On 6.12.2011 17:48, Andriy Gapon wrote:
Just for your information.
It seems that ld from binutils-2.22 by default has
--no-copy-dt-needed-entries
behavior, and so explicit --copy-dt-needed-entries is now needed where the
previous default behavior is relied upon.
A short excerpt from the man page for your convenience:
This option also has an effect on the resolution of symbols in
dynamic libraries. With --copy-dt-needed-entries dynamic libraries
mentioned on the command line will be recursively searched,
following their DT_NEEDED tags to other libraries, in order to
resolve symbols required by the output binary. With the default
setting however the searching of dynamic libraries that follow it
will stop with the dynamic library itself. No DT_NEEDED links will
be traversed to resolve symbols.
What do we do with this?
We can go back, patch to behave as before or to continue.
Are there any serious complaints?
I am not sure. Eventually all upstreams of our ports will have to deal with
this. So far I've encountered only one problematic port (gegl) that links a
binary with -lglib-2.0 expecting that a required -liconv dependency would be
automatically picked up via DT_NEEDED. libglib-2.0.so indeed has a DT_NEEDED
entry for libiconv.so. But this dependency is not explicitly advertised via
pkg-config metadata:
$ fgrep -i Libs /usr/local/libdata/pkgconfig/glib-2.0.pc
Libs: -L${libdir} -lglib-2.0
Libs.private: -liconv
So there could be other issues related to this in the future.
Perhaps this is actually an issue with glib, maybe it should have -liconv in
Libs. I am not really knowledgeable about his stuff.
As far, as I understand the
http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html ,
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition ,
http://old.nabble.com/Make-no-copy-dt-needed-default--td32272377.html ,
correctly
1. upstreams (e.g. Glib) had a pretty much time for test this change.
2. If I just use Glib (for example), then all Glib's iconv-related
stuffs will continue to work, I don't need to explicitly add -liconv.
All that fail if I use iconv_open() (for example) directly and
(bypassing Glib) and rely on Glib to load libiconv as side-effect. Of
courcse, it would be quite wrong from my side because existence of
libconv as an Glib charset conversion engine is an implementation
detail that may change at the some day or just because of different
configuration options. Just like GnuTLS swtiched from libgcrypt to
libnettle.
3. Of course, something may fail, but I would not to expect a big
amount of failures (due to the fact that major Linux distros already
there)
--
Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: gnutls update fails on libchamplain
On Tue, Jun 7, 2011 at 23:10, Johan Hendriks jo...@double-l.nl wrote: Hello all, I did an cvsup of the ports tree, read /usr/ports/UPDATING. It tells me that the new gnutls requires the following comman. portmaster -r gnutls. but this is the result [skip] /libexec/ld-elf.so.1: Shared object libgnutls.so.40 not found, required by libchamplain-0.8.so.1 It is the reason (above). For some reason the installed version of libchamplain-0.8.so.1 was catched and passed to the linker (instead of freshly built one). Workaround: deinstall already installed package and rebuild the new -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: libxul dumps core with 'illegal hardware instruction' with newly ported 'pytrainer'
On Tue, Apr 5, 2011 at 10:06, Stefan Walter ste...@freebsd.org wrote: (I didn't get any replies on freebsd-gecko@, so I thought I'd just send it on freebsd-ports@, too.) Hi, I'm working on a port for pytrainer (see [1]), which uses libxul to display GPS tracks via Google Maps or OSM. Starting the software, it crashes with illegal hardware instruction and leaves a core dump behind. Something compiled for CPU model higher than CPU, which actually run the resulting binary? For example, if I compile with -march=native on the Core2 machine and then try to run resulting binary on Pentium4, then I will obtain Illegal Instruction with very high probability. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Removal of libtool-2.4 in favor of libtool-2.2, why?
On Wed, Jan 12, 2011 at 01:13, Ade Lovett a...@freebsd.org wrote: On Jan 11, 2011, at 16:21 , Andrew W. Nosenko wrote: Can I ask autotool's maintainer(s) (sorry, it hard to determine human's name from autotools@ alias) to upgrade devel/libtool from libtool-2.2 to libtool-2.4 and, as consequence and for completeness, libltdl-2.2 to libtool-2.4? 1. devel/libtool24 (and devel/libltdl24) were never integrated into the ports tree 2. as is usual with these things, a whole bunch of stuff tends to break on each update, requiring numerous experimental runs to determine and fix issues (don't even _ask_ about gnu make 3.81-3.82) 3. not everything that uses libtool also uses autoconf 4. a whole bunch of other work was doing to clean up massive over-infestation of autotools versions, leaving us with a legacy and a current version for autoconf/automake, and a lot less intrusive (in terms of the ports tree itself) patching in the future 5. there was absolutely no way to get another set of experimental runs in for the libtool 2.2-2.4 conversion before ... 6. ... the ports freeze we are now in for 7.4 and 8.2, during which time no infrastructural and sweeping changes are permitted to give us some chance at generating a full package set for these releases 7. even limited local testing shows that libtool-2.4 is not backwards-compatible with 2.2.x (there's a shocker) :-(( The sad surprise :-( Can you point me to example? Anything from the NEWS and google search results doesn't point me to the somethig thet could to be real-live problem... And, of course, I'm uderstand point of view that even little chance to break even little thing overweights kilometers of warnings at this stage. Warnings can be simple grep'ed out, while broken build... is a broken build. 8. we're not human; even if we were at some point, after dealing with this stuff, not a chance. So, yes, it'll eventually happen; no, it won't happen immediately; yes, it'll most likely happen soon(tm) after 7.4 and 8.2; yes, it'll definitely be a painful and annoying process as always. -aDe -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Removal of libtool-2.4 in favor of libtool-2.2, why?
At the time of collapsing of the two ports (devel/libtool22 and devel/libtool24) into single one (devel/libtool) the survived occur libtool-2.2 (formely devel/libtool22). Why? I'm very confused, especially considering that libtool-2.2 is not fully compatible with autoconf-2.68 and one of the main reasons for libtool-2.4 was this autoconf-2.68 compatibility Can I ask autotool's maintainer(s) (sorry, it hard to determine human's name from autotools@ alias) to upgrade devel/libtool from libtool-2.2 to libtool-2.4 and, as consequence and for completeness, libltdl-2.2 to libtool-2.4? -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Tue, Nov 23, 2010 at 03:42, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 11/23/10 02:14, Andrew W. Nosenko wrote: On Mon, Nov 22, 2010 at 22:20, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: But there lives another problem: Xerces people doesn't expect parallel installation of the evelopment part of Xerces-C (headers, pkg-config, etc). At least it seems so by listing the libxerces-c package from Ubuntu. I guess so, but some ports of the FreeBSD ports (i.e. textproc/xalan-c) want xerces-c2 (which is 2.7.0). I try build xalan-c with the new xerces-c3 and see if it can handle the new header and libraries. I see three variants: (1) simple: just mark these ports (c2 and c3) as conflicting, ... in my testcase I did. And, for my personal taste, it is the best option. Be close to upstream as much as possible, IMHO, is the best way. (2) semi-simple: split each xerces-c port at the two: run-time and development. Runtime contains a shered library, development contains anything other. Mark development parts as conflictitng. ... well, in such a case we converge much to the weird Linux mess, I guess. (3) move each port away from each other's way: move headers into own versioned deirectory (e.g. from include/xercesc/ to insclude/xercesc-3.1/xercesc/), drop libxerces-c.so (if any -- I don't know), rename pkg-config (.pc) file, and static library (if any), may be something yet another, like documentation -- need to look at the actual install. All these changes hidden from the users through pkg-config's .pc, therefore only one problem for developers will be changed (non-standard name of the .pc file, i.e. pkg-config's module). ... this would bring up other complications for ports expecting libs and headers at places where the solo installation normally resides. But ATM I see no better way to allow parallel installation of the packages that aren't intended for parallel installation by theirs authors... I tend to install it as a unique port with conflicts activated. Hope there are no further conflicts other than xalan-c. And I have some feelings that either existing xalan-c able to compile against current xerces-c or there is newer version that able. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Fri, Nov 19, 2010 at 19:28, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 11/19/10 18:11, Andrew W. Nosenko wrote: 2010/11/19 O. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@zedat.fu-berlin.de wrote: Hello. Trying to do my first port and run into trouble. The software package (Xerces-c 3.1.1) comes with a full autotoll environment and so far building and installing works. But the libarary name is libxerces-c-3.1.so and I need to change this to respect the FreeBSD nameing schemes to libxerces-c.so.31. I'm looking for a way avoiding some post-install: stuff. There isn't any problem with the libxerces-c-3.1.so name. From http://www.freebsd.org/doc/en/books/porters-handbook/special.html Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. Well, this is the problem. The automated installation process installes libxerces-c-3.1.so. This not a problem. Inability to catch the libxerces-c-3.1.so by specifying -lxerces-c linker flag (and enforce you to specify -lxerces-c-3.1) is intended and desired effect. Please, don't touch the library name. Usually, authors change library name if want to ensure and express complete API and ABI break without any forward and backward compatibility. Like switch from Glib-1.x (libglib.so.x) to Glib-2.x (libglib-2.0.so.x). In both your (libxerces) and my (libglib) examples the authors desired to use interface generation numbers, but it just for aesthetics reasons, indeed the libraries could be renamed to any other arbitrary way (for example, libNewGlib.so and libEvenBetterXerces.so -- ideologically and technically there no differences). If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all application that want and expect the old zero-generation API and link against '-llibxerces-c' will fail because will catch absolutely unexpected (by them) and incompatible libxerces-c-3.1 API. Applications that indeed want and expect libxerces-c-3.1 API, and therefore that links with '-llibxerces-c-3.1' will fail also. Just because there no more libxerces-c-3.1.so library -- it was renamed to unexpected name w/o good reasons. Conclusion: Please, don't touch library names! Well, maybe here is a misunderstanding. Sure. See below. I'd like to come along with FreeBSD's library naming scheme when installing the library into /usr/local/lib. I thought manipulating the source-environment when compiling would be the least-efford way, but I see, maybe it would be easier to come along with a post-install: target by simply moving and making a symbolic link. If so, I need to detect by the framework what the lib vendor has choosen as thi lib name, to automate the proceed perfectly. Is this possible? Seems, like you think that Xerces authors use libNAME-VER.so naming scheme, while FreeBSD uses libNAME.so.VER ... Ineed it's simple not true. Both uses libNAME.so[.VER]. Usually, libNAME.so.VER with greatest VER symlinked to libNAME.so. How VER represented (it just a number, or more complicated like .N, .N.M., .N.M.K... -- depends on the ld.so implementation on the target system and usually should not bother you as software author (if you use Libtool, which is good in job of hiding differences between systems in that respect). Also, these .N[.M[.K]] represent the ABI version of library and has nothing with package version. Just in the case of Xerces, the NAME contains digits that looks like version (version of package). But indeed, the NAME in your case _is_ libxerces-c-3.1. I unable to say what ABI version VER is without building Xerces-C, or upstream authors decided to left it empty indeed, sorry. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Mon, Nov 22, 2010 at 22:20, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 11/22/10 19:20, Andrew W. Nosenko wrote: On Fri, Nov 19, 2010 at 19:28, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 11/19/10 18:11, Andrew W. Nosenko wrote: 2010/11/19 O. Hartmannohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@zedat.fu-berlin.de wrote: Hello. Trying to do my first port and run into trouble. The software package (Xerces-c 3.1.1) comes with a full autotoll environment and so far building and installing works. But the libarary name is libxerces-c-3.1.so and I need to change this to respect the FreeBSD nameing schemes to libxerces-c.so.31. I'm looking for a way avoiding some post-install: stuff. There isn't any problem with the libxerces-c-3.1.so name. From http://www.freebsd.org/doc/en/books/porters-handbook/special.html Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. Well, this is the problem. The automated installation process installes libxerces-c-3.1.so. This not a problem. Inability to catch the libxerces-c-3.1.so by specifying -lxerces-c linker flag (and enforce you to specify -lxerces-c-3.1) is intended and desired effect. Please, don't touch the library name. Usually, authors change library name if want to ensure and express complete API and ABI break without any forward and backward compatibility. Like switch from Glib-1.x (libglib.so.x) to Glib-2.x (libglib-2.0.so.x). In both your (libxerces) and my (libglib) examples the authors desired to use interface generation numbers, but it just for aesthetics reasons, indeed the libraries could be renamed to any other arbitrary way (for example, libNewGlib.so and libEvenBetterXerces.so -- ideologically and technically there no differences). If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all application that want and expect the old zero-generation API and link against '-llibxerces-c' will fail because will catch absolutely unexpected (by them) and incompatible libxerces-c-3.1 API. Applications that indeed want and expect libxerces-c-3.1 API, and therefore that links with '-llibxerces-c-3.1' will fail also. Just because there no more libxerces-c-3.1.so library -- it was renamed to unexpected name w/o good reasons. Conclusion: Please, don't touch library names! Well, maybe here is a misunderstanding. Sure. See below. I'd like to come along with FreeBSD's library naming scheme when installing the library into /usr/local/lib. I thought manipulating the source-environment when compiling would be the least-efford way, but I see, maybe it would be easier to come along with a post-install: target by simply moving and making a symbolic link. If so, I need to detect by the framework what the lib vendor has choosen as thi lib name, to automate the proceed perfectly. Is this possible? Seems, like you think that Xerces authors use libNAME-VER.so naming scheme, while FreeBSD uses libNAME.so.VER ... Well, after building a vanilla xerces-c version 3.1.1 and checked the vendor's point of view how the lib should be named, I guess my thinking is right about libNAME-VER.so. Simply try download and compile/install the sources from http://xerces.apache.org/xerces-c/. Ineed it's simple not true. Both uses libNAME.so[.VER]. I doubt this, or I do something stupid everytime again and again. Yes. You mess the package version (3.1 oe 3.1.1 in your case) with the ABI version (.0 or empty, in this case AFAIU). Usually, libNAME.so.VER with greatest VER symlinked to libNAME.so. How VER represented (it just a number, or more complicated like .N, .N.M., .N.M.K... -- depends on the ld.so implementation on the target system and usually should not bother you as software author (if you use Libtool, which is good in job of hiding differences between systems in that respect). Also, these .N[.M[.K]] represent the ABI version of library and has nothing with package version. Just in the case of Xerces, the NAME contains digits that looks like version (version of package). But indeed, the NAME in your case _is_ libxerces-c-3.1. I unable to say what ABI version VER is without building Xerces-C, or upstream authors decided to left it empty indeed, sorry. The new xerces-c 3.1.1 comes with a whole/complete autotools-environment. There is a m4-folder containing libtool.m4. I tried to patch this in the section freebsd-elf* and freebsd-* to reflect the naming scheme FreeBSD uses (libNAME.so.VER). I tried several variations, but it seems that Simple don't touch and you will comply! The NAME part here is xerces-c-3.1. Not NAME=xerces-c and VER=3.1 but NAME=xerces-c-3.1 and VER is empty. Again: 3.1 is the part of NAME! something from the ports toplevel Makefile isn't triggering a reconfiguration
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
2010/11/19 O. Hartmann ohart...@zedat.fu-berlin.de: On 11/19/10 13:46, Koop Mast wrote: On Fri, 19 Nov 2010 12:32:33 +0100 O. Hartmannohart...@zedat.fu-berlin.de wrote: Hello. Trying to do my first port and run into trouble. The software package (Xerces-c 3.1.1) comes with a full autotoll environment and so far building and installing works. But the libarary name is libxerces-c-3.1.so and I need to change this to respect the FreeBSD nameing schemes to libxerces-c.so.31. I'm looking for a way avoiding some post-install: stuff. There isn't any problem with the libxerces-c-3.1.so name. From http://www.freebsd.org/doc/en/books/porters-handbook/special.html Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. Well, this is the problem. The automated installation process installes libxerces-c-3.1.so. This not a problem. Inability to catch the libxerces-c-3.1.so by specifying -lxerces-c linker flag (and enforce you to specify -lxerces-c-3.1) is intended and desired effect. Please, don't touch the library name. Usually, authors change library name if want to ensure and express complete API and ABI break without any forward and backward compatibility. Like switch from Glib-1.x (libglib.so.x) to Glib-2.x (libglib-2.0.so.x). In both your (libxerces) and my (libglib) examples the authors desired to use interface generation numbers, but it just for aesthetics reasons, indeed the libraries could be renamed to any other arbitrary way (for example, libNewGlib.so and libEvenBetterXerces.so -- ideologically and technically there no differences). If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all application that want and expect the old zero-generation API and link against '-llibxerces-c' will fail because will catch absolutely unexpected (by them) and incompatible libxerces-c-3.1 API. Applications that indeed want and expect libxerces-c-3.1 API, and therefore that links with '-llibxerces-c-3.1' will fail also. Just because there no more libxerces-c-3.1.so library -- it was renamed to unexpected name w/o good reasons. Conclusion: Please, don't touch library names! -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: OPTIONS
On Wed, Oct 6, 2010 at 11:40, David O'Brien obr...@freebsd.org wrote: On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: 2010/10/3 Matthew Seaman m.sea...@infracaninophile.co.uk: In fact, you might just as well write a small HTML form, display it using lynx or w3c or some other text mode browser[*], and then have the form action feed into a CGI program that outputs a small Makefile with appropriate variable definitions in it. I like this statement -- as it shows just how complex this will get when taken to its natural conclusion. This is also how ridiculous things can get: curl 7.21.1 now offers me: [X] WERROR Treat compilation warnings as errors Can the port maintainer really not decide if that should just be turned off or turned on for FreeBSD?!? I wonder why -Werror even ever considered to be turned on at all. Do *I* really need to think about this one? But of course it doesn't offer me turning on NOPORTDOCS or NOPORTEXAMPLES, which would be useful. [I don't think any ports do...] cscope 15.7a offers me: [ ] XCSCOPE Install (X)Emacs package Do we really need to be bothered with OPTIONS to avoid installing an 87K .el file?!? Yes. I'm, as everyday cscope and emacs user, would be very frustrated if xcscope.el would be installed by ports overriding my patched version and forcing me to patch it again and again. Why xcscope.el didn't splinted out into separate port/package -- it's another question... -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Strange contents on some ftp mirrors
On Wed, Jul 28, 2010 at 18:39, Dominic Fandrey kamik...@bsdforen.de wrote: On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. Excuse me? The ports check downloaded source tarball against SHA checksum. Just for nay case like downloading error or malicious inject. Did you try to say that binary package have no such safeguard? I expect to release it at the end of September. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: compile a port with debugging symbols?
On Thu, Nov 26, 2009 at 18:10, Michael W. Lucas mwlu...@blackhelicopters.org wrote: Hi, Is there an approved/offical way to compile a port with debugging symbols? Habitually I've just run make configure and then edited Makefiles. But I'm sure that's not what you folks recommend users do... IIRC, the WITH_DEBUG=yes knob is what you looking for. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: portupgrade -R order
On Tue, May 19, 2009 at 11:58 PM, Stephen Montgomery-Smith step...@missouri.edu wrote: My experience is that openoffice will NOT build properly if gcc43 is installed. So maybe it deinstalled gcc43, built openoffice, and then rebuilt gcc43. No. Gcc-4.3 is primary compiler for my projects and OOo also need often for me. Therefore both are installed. And I never seen any conflict. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: portupgrade -R order
On Tue, May 19, 2009 at 6:17 PM, Andrea Venturoli m...@netfence.it wrote: Hello. I have a question about the order in which portupgrade -R handles ports. If I issue: portupgrade -R it-openoffice.org it will upgrade openoffice.org, *then* gcc43. I would guess openoffice.org requires gcc43 to build, but then, shouldn't it be handled *before*? Whether OOo requires gcc-4.3 indeed? Not customized version of gcc-3.4 (ooo-gcc if I recall correctly...)? About another ports: the was majority of prorts doen't require any specific GCC version supplied in ports, but use system-default gcc instead (/usr/bin/gcc), therefore, order of building gcc-4.3 from ports is irrelevant. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: shells/bash-4.0 port horribly broken
On Thu, Mar 12, 2009 at 1:48 PM, Stefan Bethke s...@lassitu.de wrote: Am 12.03.2009 um 11:29 schrieb Emanuel Haupt: $ sudo make === Vulnerability check disabled, database not found = bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo. = Either /usr/ports/shells/bash/distinfo is out of date, or = bash-4.tar.gz is spelled incorrectly. *** Error code 1 Stop in /usr/ports/shells/bash. Update: After a recent ports tree update bash now builds correctly here. The update still remains broken: [foo...@portjail ~]$ pkg_info bash-static-4.0.10_1 The GNU Project's Bourne Again SHell [r...@portjail ~]$ set -x [r...@portjail ~]$ echo $(uname) -bash: command substitution: line 25: syntax error near unexpected token `)' -bash: command substitution: line 25: `uname)' I also find this rather annoying. I believe that a rather large percentage of people use bash as their default shell, so moving from 3.2 to 4.0 should have been preceded by a headsup or an entry in UPDATING. Hmm... But record in UPDATING won't cure the bug itself. Or error in the parsing $ echo $(ls) construct is not a bug? If it is not a bug but intended behavior, then could someone point me to the appropriate part of documentation? -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: shells/bash-4.0 port horribly broken
On Thu, Mar 12, 2009 at 4:37 PM, Johan van Selst joh...@stack.nl wrote: Jerry wrote: Was this some sort of 'improvement' by the Bash developers, or is it an un-squashed bug? It seems that this might actually be a feature. Quoting the COMPAT document of bash4: 38. Since bash-4.0 now follows Posix rules for finding the closing delimiter of a $() command substitution, it will not behave as previous versions did, but will catch more syntax and parsing errors before spawning a subshell to evaluate the command substitution. Sorry, but I didn't see how it can be applied. In another words, how the 'ls' command in the $ echo $(ls) contradicts with POSIX. http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03 With the $( command) form, all characters following the open parenthesis to the matching closing parenthesis constitute the command. Any valid shell script can be used for command, except a script consisting solely of redirections which produces unspecified results. Sure, 'ls' is not a something that consisting solely of redirections. -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: Dead projects in ports tree
On Tue, Mar 3, 2009 at 10:26 AM, Garrett Cooper yanef...@gmail.com wrote: On Mon, Mar 2, 2009 at 3:34 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote: I completely agree. So long as a port is being used and people find it useful, I think it would be a mistake to remove those ports. In fact I suspect it wouldn't be long before someone was submitting a PR to reinstate the port. Perfect example is converters/unix2dos, last updated in 2003 and converters/mpack, last updated in 2006. I still use both, and I would be irritated if they were removed from ports. A lack of development activity != a lack of usefulness I agree for projects like that that are feature complete. However, projects like xmms drag on the use of gtk 1.2 and will soon be out of date in terms of file formats, decoding capability, etc. Then again I suppose when that day comes xmms will be marked busted and eventually shuffled out of the tree, so I'll shut my trap about that :). And what? Until gtk+-1.2 removed from ports, the xmms perfectly able to compile and run, at least from the gtk+ dependency side. Anyone, who don't like gtk-1.2 installed may just don't install both xmms and gtk+-1.2, just like me. Personal preferences are just personal preferences and no more. About file formats: my 5 years hardware dvd player also has limited decoding capability and formats support in comparison with today ones, but these capabilities are enough for me. And it still work. Now question: why I need to replace it if all just works and fits my requirements? The same logic may be applied to software too: why drop/replace if it just works? When it xmms occur to be uncompiliable or unable to run -- then yes, it may be reason to abandon it. But when it works ... see no reasons to remove. Frankly, I would glad to see absolutelly another discussion: not about dropping software that works (and as far as I understand, which port is maintained), but about making needed but broken software work again (e.g. valgrind, which is compiliable, but absolutelly not runnable since freebsd-7.0, and unfortunatelly has no replacement...) -- Andrew W. Nosenko andrew.w.nose...@gmail.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
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
On Thu, Dec 11, 2008 at 10:23 AM, Dmitry Marakasov [EMAIL PROTECTED] wrote: * Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote: This is what Debian and Gentoo does. Remember we don't have to pass DESTDIR variable to 'make -C /usr/ports/editors/emacs-cvs' instead it will be passed to the 'gmake' process invoked by port's Makefile. If we I understand. But you're implying that there is Makefile and it supports DESTDIR. As I understand, you're referring to autotools-based ports. Remember, those are less than 1/4 of the collection. Excuse me, but he refers not to autotools-based ports, but to ports that follows GNU Coding Standards (section Makefile Conventions if more preciously). Autotools just brings such support out-of-the-box. And, IMO, projects that violates these things heavy, should be fixed upstream. BTW, from my expiriense, there are little amount of project that doesn't support DESTDIR of it's analog. And many of them may be worked around anyway. -- Andrew W. Nosenko [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xdelta 1.1.4 issues
On Fri, Aug 15, 2008 at 5:45 AM, Isaac Grover [EMAIL PROTECTED] wrote: Good evening from Wisconsin, This post is regarding the xdelta-1.1.3 port included in FreeBSD 6.2-RELEASE. Please direct me to the proper mailing list if this is not where I should be posting. I am attempting to use xdelta on tar files currently just over 8.2GB. My syntax to get the delta is xdelta delta oldtarfile newtarfile patchfile according to the man page. When the patchfile has been created, it is around 5.3MB in size. To verify the patchfile, using xdelta patch patchfile oldtarfile newtarfiletest yield a newtarfiletest of 465MB. Available space shouldn't be an issue, as I have 22GB available on this partition. Not about xdelta itself but about space-related problems: sometime an space-related failures goes from not enough _temporary_ space (/tmp, /var/tmp, directory pointed by $TMPDIR...) -- Andrew W. Nosenko [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Little valgrind issue
On Tue, May 6, 2008 at 6:05 PM, Gé Weijers [EMAIL PROTECTED] wrote: Hello, I tried to build 'valgrind' in a jail environment. The Makefile tries to make sure that /proc is mounted before it build valgrind, which is fine, but the way it does it won't work in a jail because /sbin/mount does not show anything useful. A quick workaround: define the environment variable 'PACKAGE_BUILDING=yes' and then run 'make' and 'make install' It would be better if the Makefile would just look for, say, the existence of '/proc/curproc' in stead of relying on /sbin/mount. I'm very surprised. Just because unable to build valgring at all since FreeBSD-7.0... :-( (New threading implementation related issue?) -- Andrew W. Nosenko [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
