pulseview 0.4.0 not linking. Help with Qt5 app build?
I'm working on new versions of the sigrok ports (libserialport, libsigrok, libsigrokdecode and pulseview being the critical bits). While the C things all build and seem to work with little problem, the GUI package - pulseview - fails to link with a bunch of references to undefined variables. Those seem to be not only things from the sigrok libraries, but some standard parts of C++ as well. I'm don't generally do much C++ or Qt work, so am out of my depth. Figures that the thing that doesn't work is the thing I have the least ability to fix. Anyway, here's the link command and the errors it generates. There were no errors before that during the build. If someone can provide a clue as to what might be missing, or what to tell cmake, to get this to work, I'd appreciate it. The old 0.3.0 port does build, but examining it hasn't turned up anything that works. Plugging in C++ libraries, using -pthread, and trying different ways to get to the clang c++ compiler all result in linker errors. Please leave my address in the Cc: list, as I'm not subscribed. /usr/bin/CC-fPIC -O2 -g -DNDEBUG CMakeFiles/pulseview.dir/main.cpp.o CMakeFiles/pulseview.dir/pv/application.cpp.o CMakeFiles/pulseview.dir/pv/devicemanager.cpp.o CMakeFiles/pulseview.dir/pv/mainwindow.cpp.o CMakeFiles/pulseview.dir/pv/session.cpp.o CMakeFiles/pulseview.dir/pv/storesession.cpp.o CMakeFiles/pulseview.dir/pv/util.cpp.o CMakeFiles/pulseview.dir/pv/binding/binding.cpp.o CMakeFiles/pulseview.dir/pv/binding/inputoutput.cpp.o CMakeFiles/pulseview.dir/pv/binding/device.cpp.o CMakeFiles/pulseview.dir/pv/data/analog.cpp.o CMakeFiles/pulseview.dir/pv/data/analogsegment.cpp.o CMakeFiles/pulseview.dir/pv/data/logic.cpp.o CMakeFiles/pulseview.dir/pv/data/logicsegment.cpp.o CMakeFiles/pulseview.dir/pv/data/signaldata.cpp.o CMakeFiles/pulseview.dir/pv/data/segment.cpp.o CMakeFiles/pulseview.dir/pv/devices/device.cpp.o CMakeFiles/pulseview.dir/pv/devices/file.cpp.o CMakeFiles/pulseview.dir/pv/devices/hardwaredevice.cpp.o CMakeFiles/pulseview.dir/pv/devices/inputfile.cpp.o CMakeFiles/pulseview.dir/pv/devices/sessionfile.cpp.o CMakeFiles/pulseview.dir/pv/dialogs/about.cpp.o CMakeFiles/pulseview.dir/pv/dialogs/connect.cpp.o CMakeFiles/pulseview.dir/pv/dialogs/inputoutputoptions.cpp.o CMakeFiles/pulseview.dir/pv/dialogs/storeprogress.cpp.o CMakeFiles/pulseview.dir/pv/popups/deviceoptions.cpp.o CMakeFiles/pulseview.dir/pv/popups/channels.cpp.o CMakeFiles/pulseview.dir/pv/prop/bool.cpp.o CMakeFiles/pulseview.dir/pv/prop/double.cpp.o CMakeFiles/pulseview.dir/pv/prop/enum.cpp.o CMakeFiles/pulseview.dir/pv/prop/int.cpp.o CMakeFiles/pulseview.dir/pv/prop/property.cpp.o CMakeFiles/pulseview.dir/pv/prop/string.cpp.o CMakeFiles/pulseview.dir/pv/toolbars/mainbar.cpp.o CMakeFiles/pulseview.dir/pv/view/analogsignal.cpp.o CMakeFiles/pulseview.dir/pv/view/cursor.cpp.o CMakeFiles/pulseview.dir/pv/view/cursorpair.cpp.o CMakeFiles/pulseview.dir/pv/view/flag.cpp.o CMakeFiles/pulseview.dir/pv/view/header.cpp.o CMakeFiles/pulseview.dir/pv/view/marginwidget.cpp.o CMakeFiles/pulseview.dir/pv/view/logicsignal.cpp.o CMakeFiles/pulseview.dir/pv/view/rowitem.cpp.o CMakeFiles/pulseview.dir/pv/view/ruler.cpp.o CMakeFiles/pulseview.dir/pv/view/signal.cpp.o CMakeFiles/pulseview.dir/pv/view/signalscalehandle.cpp.o CMakeFiles/pulseview.dir/pv/view/timeitem.cpp.o CMakeFiles/pulseview.dir/pv/view/timemarker.cpp.o CMakeFiles/pulseview.dir/pv/view/trace.cpp.o CMakeFiles/pulseview.dir/pv/view/tracegroup.cpp.o CMakeFiles/pulseview.dir/pv/view/tracepalette.cpp.o CMakeFiles/pulseview.dir/pv/view/tracetreeitem.cpp.o CMakeFiles/pulseview.dir/pv/view/tracetreeitemowner.cpp.o CMakeFiles/pulseview.dir/pv/view/triggermarker.cpp.o CMakeFiles/pulseview.dir/pv/view/view.cpp.o CMakeFiles/pulseview.dir/pv/view/viewitem.cpp.o CMakeFiles/pulseview.dir/pv/view/viewitemowner.cpp.o CMakeFiles/pulseview.dir/pv/view/viewitempaintparams.cpp.o CMakeFiles/pulseview.dir/pv/view/viewport.cpp.o CMakeFiles/pulseview.dir/pv/view/viewwidget.cpp.o CMakeFiles/pulseview.dir/pv/widgets/colourbutton.cpp.o CMakeFiles/pulseview.dir/pv/widgets/colourpopup.cpp.o CMakeFiles/pulseview.dir/pv/widgets/devicetoolbutton.cpp.o CMakeFiles/pulseview.dir/pv/widgets/exportmenu.cpp.o CMakeFiles/pulseview.dir/pv/widgets/hidingmenubar.cpp.o CMakeFiles/pulseview.dir/pv/widgets/importmenu.cpp.o CMakeFiles/pulseview.dir/pv/widgets/popup.cpp.o CMakeFiles/pulseview.dir/pv/widgets/popuptoolbutton.cpp.o CMakeFiles/pulseview.dir/pv/widgets/sweeptimingwidget.cpp.o CMakeFiles/pulseview.dir/pv/widgets/timestampspinbox.cpp.o CMakeFiles/pulseview.dir/pv/widgets/wellarray.cpp.o CMakeFiles/pulseview.dir/signalhandler.cpp.o CMakeFiles/pulseview.dir/pv/binding/decoder.cpp.o CMakeFiles/pulseview.dir/pv/data/decoderstack.cpp.o CMakeFiles/pulseview.dir/pv/data/decode/annotation.cpp.o CMakeFiles/pulseview.dir/pv/data/decode/decoder.cpp.o CMakeFiles/pulseview.dir/pv/data/decode/row.cpp.o CMakeFiles/pulseview.dir/pv/data/decode/rowdata.cpp.o
License compatibility issues?
After a discussion on another list, I'm wondering if anyone has ever done anything to verify that the license requirements of the dependencies of a package (I don't know of any licenses that would cause problems for a port, as those don't involve distribution of derived works in the form of a binary) are actually met? For instance, a port licensed under the EPL that is statically linked with a GPL'ed library would produce a binary that couldn't be legally distributed. Searching google didn't turn much up, but I do notice that bsd.license.txt doesn't worry about the license requirements of dependencies. Since it is run at build time, this isn't a problem, as the license issues we deal with will turn up when the dependencies are built. But incompatible licenses don't seem to be dealt with at all. Maybe I just need better google search words? ___ 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: amd64/121951: Javascript bug in _amd64_ version of Mozilla-Firefox
The following reply was made to PR amd64/121951; it has been noted by GNATS. From: Mike Meyer [EMAIL PROTECTED] To: Bill Squire [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: amd64/121951: Javascript bug in _amd64_ version of Mozilla-Firefox Date: Sat, 22 Mar 2008 11:45:42 -0400 On Sat, 22 Mar 2008 03:52:30 +0100 (CET) Bill Squire [EMAIL PROTECTED] wrote: How-To-Repeat: goto: http://maps.google.com/ and note there are NO maps -- anywhere 100% repeatable -- problem has developed over the past six months. maps.google.com works fine for me on 7.0-RELEASE/amd64. goto: http://slashdot.org/, login and try to Retrieve more of (at the bottom of the page) Try to set preferences or any other 'ajax-style' window 100% repeatable -- has developed over 1/2 a year. Can you create an account to demonstrate this, as they have chosen to block bugmenot. Other very minor failures at various sites: (highly variable) Launching video at various news sites (non-flash) usually implies manual loading into a mediaplayer or 'carefully timed manipulation'. BBC, CBC, VARA, VPRO etc. Note: Some sites, particularly in the US, try to prevent non-Windows usage. (This may or may not be related to this.) In my experience, most sites on the internet are buggy to some degree or another. In particular, almost *all* of them are sensitive to what should be minor variations in the client configuration. The closer you are to the authors standard configuration (almost inevitably a slightly dated version of IE on a similarly dated version of 32bit Windows in their out of the box configuration with the server on the local lan), the more likely things are to work for you. Three of your own suggested fixes are Run something more like what the author runs: Run the Linux32 version -- Usually works well. Run the native 32bit version on an i386 (athlon-xp) or Run the 32bit version under emulation on amd64. (in a jail) (Both the real and 'emulated' i386 work error-free.) So, you might try: 1) Creating a new users with all software configured to it's default state. 2) Remove any system-level config info for the relevant software. 3) Reinstall said software. If you're compiling from source, reset the config to the defaults. As to the other fixes, they may be good advice, but aren't things that can be done in the FreeBSD source tree. Fix: Some sites should be aware of this and perhaps write better scripts. Personally, I decided the barbarians had won 15 years ago, and gave up the fight. But good luck with it. Turn off javascript when practical Good security advice. You should also restart the browser after each site to kill xss code. Learn Javascript-2.0! mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. Unfortunately you deleted the sentence before, so I rephrase it: before looking into optimizations find out where the time is actually spend - how many seconds of the hours the process takes, are actually spent in make and sub-makes. If the entire process takes 2 hours of which the makes take 20 seconds then by enhancing performance of make by 50% you win 10 seconds. This is probably not worth a single line of additional code. The paper you point to talks about something entirely different. It think we're talking about two different things. You're talking about the efficiency of make, whereas he's talking about the efficiency of make. Um, wait. You're talking about what I'll call the *internal* efficiency of make, defined as how fast it does the things it does. He's talking about what I'll call the *external* efficiency of make, which is how well it does at doing the minimum amount of work it needs to do. I hope you can see where the confusion comes from. In particular, he talks about how recursive makefiles screw up evaluating complex variables, causing them to be executed multiple times. So if you're running a makefile to pull some variables value, as opposed to do real commands, and your entire process takes 2 hours and the Makefile takes 20 seconds, but it evaluates all the variables twice, then by fixing your makefile you win at least 59 minutes and 50 seconds. I think cutting the run time by 50% is worth some work. Benchmarking can help you decide which things it pays to work on if all you're worried about is the internal efficiency. However, the goal is to make the process faster, so we need to worry about the external efficiency as well. The problem here is that the worse it is, the less it looks like you stand to gain by looking at your makefile when you look at the benchmarks. Given that the ports system has both highly complex variables and is very recursive, I believe that it warrants investigation if you're going to work on making make in the ports faster. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index
In [EMAIL PROTECTED], Edwin Groothuis [EMAIL PROTECTED] typed: On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote: In summary, the ports infrastructure is really complicated because it's trying to deal with all kinds of constraints and conditions. I challenge Reading this, I was wondering what the ports infrastructure has ever done for us? See http://www.epicure.demon.co.uk/whattheromans.html While that's funny, it makes me wonder if you're serious when you ask the question. The ports system is a wonder. If you've ever tried installing software off the net without such a thing to help, you'll know what I mean. If you haven't, you should thank jkh for your state of blessedness. That said, it's now a decade old, and I'm sure doing far more than jkh ever expected of it. It's also tightly integarted with the package system, which is in a similar state. Both are suffering in comparison to newer systems, many of which have less ambitious goals. It seems like in the last month or so a lot of people have popped up with an interest in reworking one or both of them. Hopefully, some of them with time to do so will get good advice. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgupgrade
In [EMAIL PROTECTED], Scott Mitchell [EMAIL PROTECTED] typed: On Sat, Feb 10, 2007 at 04:40:28PM +0100, Michel Talon wrote: Hello, this is to report a revised version of my program, intended to upgrade a machine using mainly precompiled packages. All problems that i have seen or have been reported to me have been fixed. So i think it is reasonably suitable for use, and i have sticked a 1.0 label. I have also fixed all problems i have encountered with save_pkg.py, but Cyrille Szymanski will perform a better cleanup, so i have appended a 0.5 tag. So fresh copies can be downloaded from: http://www.lpthe.jussieu.fr/~talon/pkgupgrade-1.0 http://www.lpthe.jussieu.fr/~talon/save_pkg.py-0.5 Good work, this script is pretty cool! One thing that might be nice to add is an option to download new packages from the packages-X-stable directory, if a newer version is found there. I think you only ever look in packages-X.Y-release at the moment, and those never change after the release as far as I know. While the option might be useful, you may want to build from source in that case. While ports that postdate X.Y are supposed to build and run correctly on X.Y (for supported values of X Y), and packages built on systems that predate X.Y are supposed to run correctly on X.Y, packages built on systems that postdate X.Y may not run correctly on X.Y. If you're already doing thorough testing of the system after you upgrade the packages, this doesn't really make much difference. But if you're expecting that the testing was done by someone else, your expectations don't match reality. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
