Hi Matthias, As far as I understand it, this looks like your misunderstanding in both 464080 and 464083. Let me explain further:
1) I already tested the latest complearn-tools version ncd, which happens to link against the libcomplearn-gomp library you are complaining about. The ncd command clearly uses multiple cores because my CPU utilization is 100% on the following command: ncd -d /usr/sbin /usr/sbin If you see the CPU meter go to "full tilt" and have more than one core, this confirms that at least the system is working how I intended. 2) I followed my understanding of the gcc documentation, which does NOT say to link against libgomp as far as I can tell. It says to use the -fopenmp flag, which happens to link in other stuff and set certain compiler switches (of which I remain blissfully unaware) etc. That is what I did and this works for me. 3) I agree with you that the libgomp1 dependency should be there for the gomp version of the library. That is why I added it hardcoded. Since I do not want to make assumptions about how the gcc -fopenmp flag implements its magic (at least, not more than I need to), I do not want to make an explicit link to libgomp1 without any indication that it helps any particular use-case. (please demonstrate this use-case if you can) Therefore, I disagree with you that "this is bad." 4) I am open to and interested in fixing real bugs. I don't think this bug is a real bug, but if it turns out I am mistaken, I invite you to demonstrate it. I would like one of the following two demonstration types to be able to reproduce the bug: a) an example ncd or maketree command that is not performing as expected. b) an example of the libcomplearn-gomp1 or libqsearch-gomp1 library not connecting to other software or allowing people to link their own C programs against it without undue hassle. Some small test programs that have built fine for me are as follows: anycompress, anydecompress, israndom Note that each of these are supposed to work with the -gomp1 or non-gomp1 versions. And because gcc documents the -fopenmp flag as the main way to use openmp, and I think this flag links with the gomp library, it would be redundant for me to link the libraries against gomp1. I am closing both bugs now because I have received no new actionable intelligence yet. If you manage to achieve any of the above demonstrations, I would appreciate your reopening the bug. I will fix both if you make a suitable demonstration of the (effects of) the (alleged) bug on either one. Thanks for your help, Rudi On Feb 5, 2008 3:17 AM, Matthias Klose <[EMAIL PROTECTED]> wrote: > reopen 464080 > reopen 464083 > severity 464080 minor > severity 464083 minor > thanks > > The dependency is now hardcoded, which is bad, plus the libraries > itself don't seem to be linked against libgomp. Please fix. > > > -- Which is worse, ignorance or apathy? Who knows? Who cares? --Erich Schubert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
