Debug symbols stripped from qt4-mac on library linking
I noticed when debugging a segfault, even though my binary was linked to the Qt_debug libraries no line numbers or other symbols were available. My investigation found that no -g flags were passed to the Makefile.Debug LFLAGS, thus when the shared library was built the symbols disappeared. I added the flags (-g -gdwarf-2 like what was in CXXFLAGS) and rebuilt Qt and retried my gdb session. I got symbols, line numbers, code listings, etc. Given that the Makefiles are generated from the qmake project files, is the bug in the way that they are generated or is this an upstream problem with the Qt release? The port was qt4-mac @4.7.4_0+debug+quartz Cheers, ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Debug symbols stripped from qt4-mac on library linking
Hi Kieran - Can you provide the versions of OS, XCode, and MacPorts that you're using? I'll admit that I have't tried debugging Qt stuff in a long time, so ... - MLD On Oct 14, 2011, at 5:37 AM, Kieran Simpson wrote: I noticed when debugging a segfault, even though my binary was linked to the Qt_debug libraries no line numbers or other symbols were available. My investigation found that no -g flags were passed to the Makefile.Debug LFLAGS, thus when the shared library was built the symbols disappeared. I added the flags (-g -gdwarf-2 like what was in CXXFLAGS) and rebuilt Qt and retried my gdb session. I got symbols, line numbers, code listings, etc. Given that the Makefiles are generated from the qmake project files, is the bug in the way that they are generated or is this an upstream problem with the Qt release? The port was qt4-mac @4.7.4_0+debug+quartz ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Debug symbols stripped from qt4-mac on library linking
Michael, I'm using OSX 10.6.7, XCode 4.0 Build 4A304a and MacPorts 2.0.3 The compiler used was /Developer/usr/bin/llvm-g++-4.2 Cheers, On 14/10/11 10:01 PM, Michael Dickens wrote: Hi Kieran - Can you provide the versions of OS, XCode, and MacPorts that you're using? I'll admit that I have't tried debugging Qt stuff in a long time, so ... - MLD On Oct 14, 2011, at 5:37 AM, Kieran Simpson wrote: I noticed when debugging a segfault, even though my binary was linked to the Qt_debug libraries no line numbers or other symbols were available. My investigation found that no -g flags were passed to the Makefile.Debug LFLAGS, thus when the shared library was built the symbols disappeared. I added the flags (-g -gdwarf-2 like what was in CXXFLAGS) and rebuilt Qt and retried my gdb session. I got symbols, line numbers, code listings, etc. Given that the Makefiles are generated from the qmake project files, is the bug in the way that they are generated or is this an upstream problem with the Qt release? The port was qt4-mac @4.7.4_0+debug+quartz ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Unsupported compiler error when building MacVim
On Oct 13, 2011, at 21:20, Brandon Allbery wrote: On Thu, Oct 13, 2011 at 18:33, Tim Johnson t...@akwebsoft.com wrote: * Brandon Allbery allber...@gmail.com [111013 14:24]: The ghc mailing list has been fighting this for a bit; it seems Xcode 4.2 no longer ships a non-llvm gcc. I suspect things are about to get interesting in OSX developer land. Things have been getting interesting since the release of Lion. Please see: https://trac.macports.org/wiki/PortfileRecipes#compiler I personally am holding off the Xcode upgrade for a while. Yikes! Are you saying that I should be using Xcode4.1? That would be one option, if you want to avoid having to deal with this stuff while we sort it out. It would probably be easier, but I was given another solution on IRC; you should file a bug against the port. jmr_mp geekosaur: indeed, this is why we've been telling everyone to check for gcc-4.2's existence and depend on apple-gcc42 if needed so the port is doing the wrong thing, and you should be able to work around by sudo port install apple-gcc42. ...and then doing: sudo port clean MacVim sudo port install MacVim configure.compiler=apple-gcc-4.2 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Forum?
On Oct 11, 2011, at 12:42, Daniel J. Luke wrote: Since MacPorts is an all volunteer project, there's nothing stopping anyone from creating a web forum and having discussions there. I recommend you don't do this. It'll just fragment the community and make it less likely that people will get the answers they're looking for. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: problem with installing doxygen
On Oct 11, 2011, at 08:42, Paul van Hoven wrote: Hi! I'd like to install doxygen. But the process terminates with the following error message: --- Fetching archive for graphviz --- Attempting to fetch graphviz-2.28.0_2.darwin_10.x86_64.tbz2 from http://packages.macports.org/graphviz --- Fetching graphviz --- Verifying checksum(s) for graphviz --- Extracting graphviz --- Applying patches to graphviz --- Configuring graphviz Error: You cannot install graphviz for the architecture(s) x86_64 because Error: its dependency /opt/local/lib/libpango-1.0.dylib is not provided by a MacPorts port. only contains the architecture(s) i386. Error: Error: Did you upgrade to a new version of Mac OS X? If so, please see Error: Error: http://trac.macports.org/wiki/Migration Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Error: Failed to install graphviz Log for graphviz is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_graphviz/graphviz/main.log Error: The following dependencies were not installed: graphviz Error: Status 1 encountered during processing. To report a bug, see http://guide.macports.org/#project.tickets I already got this error message and since I updated from leopard to snow leopard about 1,5 years ago I thought I follow the instructions given on http://trac.macports.org/wiki/Migration. But the error above is the error I recieve after doing all the stuff suggested behind this link. So I don't think that this is an error caused by migration. But I have no idea how to proceed. Somehow, your pango library is not registered to a MacPorts port. Of course, it should be registered to the pango port. If this is the only file in this predicament, you can forcibly install pango again. But I don't find that to be likely; you'll probably run into other files in a similar situation. So I recommend uninstalling MacPorts and all ports (see the guide for instructions), then reinstalling MacPorts and the ports you want. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MAMP www.mamp.info and macports' phpMyAdmin compatibility
On Oct 9, 2011, at 06:14, Peng Yu wrote: I have installed MAMP through www.mamp.info, which is much simpler than MAMP from macports. Then I wan to install phpMyAdmin with macports. I'm wondering if phpMyAdmin with macports is compatible with MAMP from www.mamp.info. Does anybody have any experience? MacPorts phpmyadmin will use MacPorts php5. If you don't specify otherwise, that will install MacPorts apache2 as well. (The alternative would be to build php5 with the +fastcgi variant and then configure whatever web server you want to use that php fastcgi binary.) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: youtube-dl bug with Russian character set? Howto fix?
On Oct 8, 2011, at 15:46, Fyodor Vassiley wrote: I have youtube-dl installed from MacPorts and downloading a YouTube clip with Russian title (Russian characters: Наша с Машей опущенность)) ). But the Russian characters are not display in the file name on my Lion. See which youtube-dl /opt/local/bin/youtube-dl youtube-dl -t http://www.youtube.com/watch?v=mQTIkBmrck0 [youtube] Setting language [youtube] mQTIkBmrck0: Downloading video webpage [youtube] mQTIkBmrck0: Downloading video info webpage [youtube] mQTIkBmrck0: Extracting video information [download] Destination: -mQTIkBmrck0.flv [download] 100.0% of 1.09M at2.29M/s ETA 00:00 ls -al -- -mQTIkBmrck0.flv -rw-r--r-- 1 fyodor staff 1147764 Apr 11 19:17 -mQTIkBmrck0.flv Should be Наша_с_Машей_опущенность))-mQTIkBmrck0.flv. When downloading the same clip with Jdownloader (Java) - no problem: ls -al *mp4 -rw-r--r-- 1 fyodor staff 1022898 Oct 8 22:34 Мочеиспускание))(240p_H.264-AAC).mp4 How to fix this? I wish to help the dev, because he has most certainly no Mac. The problem doesn't exists on Linux. I'm sorry, I don't know. You'd probably best file a bug report so the problem is forgotten, but I don't know how to fix it so someone else will have to find out and tell me. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port upgrade outdated from 2.0.2 to 2.0.3 messed up user database
While I don't think this has anything to do with this thread... On Oct 10, 2011, at 19:15, Jeremy Lavergne wrote: Have we completely dropped the ball on informing users to run selfupdate twice? When you selfupdate *from* MacPorts 2.0.2 or later you'll be told to run selfupdate a second time. MacPorts 2.0.1 and earlier didn't know to tell you to do that so you just have to know. I feel that, if that's the case, we should start ensuring that selfupdate can run itself twice (looks a file to signal do selfupdate). That would be a possible enhancement, but of course, it won't help anybody upgrading *from* any existing version of MacPorts. It'll only help us in the future. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port upgrade outdated from 2.0.2 to 2.0.3 messed up user database
On Oct 14, 2011, at 20:12, Ryan Schmidt wrote: I feel that, if that's the case, we should start ensuring that selfupdate can run itself twice (looks a file to signal do selfupdate). That would be a possible enhancement, but of course, it won't help anybody upgrading *from* any existing version of MacPorts. It'll only help us in the future. But be sure you understand what the problem is. Prior to MacPorts 2.0.2, selfupdate did this: 1. The old version of MacPorts runs sync to download the new portfiles 2. The old MacPorts indexes those new ports 3. The old MacPorts downloads the code for the new version of MacPorts 4. The old MacPorts compiles the new MacPorts 5. The old MacPorts exits; any subsequent invocation of port will be the new version The order may not be completely correct but the point is that the problem is that the old MacPorts is not capable of correctly indexing the ports that were just downloaded, if the ports contain new syntax only understood by the new MacPorts. Therefore MacPorts 2.0.2 and up skips step 2 if a new version of MacPorts has been downloaded, and prints a message telling the user to run selfupdate again. When the user does so, it'll be the new version of MacPorts running that is capable of indexing the ports correctly. If you wanted to make this all work in a single selfupdate run, you'd have to have a way for the old MacPorts to launch the new MacPorts to do the indexing. That might be tricky. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port upgrade outdated from 2.0.2 to 2.0.3 messed up user database
On Oct 14, 2011, at 9:46 PM, Ryan Schmidt wrote: But be sure you understand what the problem is. Prior to MacPorts 2.0.2, selfupdate did this: 1. The old version of MacPorts runs sync to download the new portfiles 2. The old MacPorts indexes those new ports 3. The old MacPorts downloads the code for the new version of MacPorts 4. The old MacPorts compiles the new MacPorts 5. The old MacPorts exits; any subsequent invocation of port will be the new version The order may not be completely correct but the point is that the problem is that the old MacPorts is not capable of correctly indexing the ports that were just downloaded, if the ports contain new syntax only understood by the new MacPorts. Therefore MacPorts 2.0.2 and up skips step 2 if a new version of MacPorts has been downloaded, and prints a message telling the user to run selfupdate again. When the user does so, it'll be the new version of MacPorts running that is capable of indexing the ports correctly. If you wanted to make this all work in a single selfupdate run, you'd have to have a way for the old MacPorts to launch the new MacPorts to do the indexing. That might be tricky. Why not, check for a new version of macports first, if found build/install new version than exec whatever version is (now) installed and have it run sync (and index what it sync'd)? -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port upgrade outdated from 2.0.2 to 2.0.3 messed up user database
On Oct 14, 2011, at 21:02, Daniel J. Luke wrote: On Oct 14, 2011, at 9:46 PM, Ryan Schmidt wrote: But be sure you understand what the problem is. Prior to MacPorts 2.0.2, selfupdate did this: 1. The old version of MacPorts runs sync to download the new portfiles 2. The old MacPorts indexes those new ports 3. The old MacPorts downloads the code for the new version of MacPorts 4. The old MacPorts compiles the new MacPorts 5. The old MacPorts exits; any subsequent invocation of port will be the new version The order may not be completely correct but the point is that the problem is that the old MacPorts is not capable of correctly indexing the ports that were just downloaded, if the ports contain new syntax only understood by the new MacPorts. Therefore MacPorts 2.0.2 and up skips step 2 if a new version of MacPorts has been downloaded, and prints a message telling the user to run selfupdate again. When the user does so, it'll be the new version of MacPorts running that is capable of indexing the ports correctly. If you wanted to make this all work in a single selfupdate run, you'd have to have a way for the old MacPorts to launch the new MacPorts to do the indexing. That might be tricky. Why not, check for a new version of macports first, if found build/install new version than exec whatever version is (now) installed and have it run sync (and index what it sync'd)? I'm assuming it would be the exec whatever version is (now) installed part that would be hard. What you suggested was also my first suggestion in the ticket I filed about the problem, but Joshua implemented it the way it's currently implemented. https://trac.macports.org/ticket/30739 Perhaps Joshua can comment further. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port upgrade outdated from 2.0.2 to 2.0.3 messed up user database
On 2011-10-15 13:20 , Ryan Schmidt wrote: On Oct 14, 2011, at 21:02, Daniel J. Luke wrote: On Oct 14, 2011, at 9:46 PM, Ryan Schmidt wrote: But be sure you understand what the problem is. Prior to MacPorts 2.0.2, selfupdate did this: 1. The old version of MacPorts runs sync to download the new portfiles 2. The old MacPorts indexes those new ports 3. The old MacPorts downloads the code for the new version of MacPorts 4. The old MacPorts compiles the new MacPorts 5. The old MacPorts exits; any subsequent invocation of port will be the new version The order may not be completely correct but the point is that the problem is that the old MacPorts is not capable of correctly indexing the ports that were just downloaded, if the ports contain new syntax only understood by the new MacPorts. Therefore MacPorts 2.0.2 and up skips step 2 if a new version of MacPorts has been downloaded, and prints a message telling the user to run selfupdate again. When the user does so, it'll be the new version of MacPorts running that is capable of indexing the ports correctly. If you wanted to make this all work in a single selfupdate run, you'd have to have a way for the old MacPorts to launch the new MacPorts to do the indexing. That might be tricky. Why not, check for a new version of macports first, if found build/install new version than exec whatever version is (now) installed and have it run sync (and index what it sync'd)? I'm assuming it would be the exec whatever version is (now) installed part that would be hard. What you suggested was also my first suggestion in the ticket I filed about the problem, but Joshua implemented it the way it's currently implemented. https://trac.macports.org/ticket/30739 Perhaps Joshua can comment further. It's not particularly hard to exec the new portindex(1), it's just unnecessary when there's already a perfectly good PortIndex we can sync from the server. You don't get the message telling you to run selfupdate again unless you are using a file:// source where the PortIndex has to be generated locally. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
