I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at this second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it? Thanks
On Fri, Aug 27, 2010 at 12:03 AM, Nathan O <ndowens.aur@gmail.com> wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at this second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
Thanks
Forgot to mention, it only states that when it is creating the package but not with namcap.
On 27/08/10 06:03, Nathan O wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at this second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
The fix for the $srcdir issue depends on the nature of the issue. Not very helpful, I know. Have a look in the ml archives for a discussion of this issue, it took place not so long ago and was started by me. There you'll find enough information to be able to do the same check that makepkg does so you can find *exactly* why it complains. If I find the time to take a closer look myself, is there a PKGBUILD available already that I can use? Where? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Fri, Aug 27, 2010 at 1:24 AM, Magnus Therning <magnus@therning.org>wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at
On 27/08/10 06:03, Nathan O wrote: this
second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
The fix for the $srcdir issue depends on the nature of the issue. Not very helpful, I know. Have a look in the ml archives for a discussion of this issue, it took place not so long ago and was started by me. There you'll find enough information to be able to do the same check that makepkg does so you can find *exactly* why it complains.
If I find the time to take a closer look myself, is there a PKGBUILD available already that I can use? Where?
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
If you would like to, http://aur.archlinux.org/packages.php?ID=22993 I will check out the archives. Thanks P.S. I searched Google last night and somebody stated to do something like "grep -R $srcdir $pkgdir"
On Fri, Aug 27, 2010 at 1:27 AM, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 1:24 AM, Magnus Therning <magnus@therning.org>wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at
On 27/08/10 06:03, Nathan O wrote: this
second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
The fix for the $srcdir issue depends on the nature of the issue. Not very helpful, I know. Have a look in the ml archives for a discussion of this issue, it took place not so long ago and was started by me. There you'll find enough information to be able to do the same check that makepkg does so you can find *exactly* why it complains.
If I find the time to take a closer look myself, is there a PKGBUILD available already that I can use? Where?
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
If you would like to, http://aur.archlinux.org/packages.php?ID=22993 I will check out the archives. Thanks P.S. I searched Google last night and somebody stated to do something like "grep -R $srcdir $pkgdir"
I used Google to search the ML with your email and name and subjects(not all in one sentence) $srcdir, references, and cmake, though I couldn't find it
On Fri, Aug 27, 2010 at 2:19 AM, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 1:27 AM, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 1:24 AM, Magnus Therning <magnus@therning.org>wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at
On 27/08/10 06:03, Nathan O wrote: this
second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
The fix for the $srcdir issue depends on the nature of the issue. Not very helpful, I know. Have a look in the ml archives for a discussion of this issue, it took place not so long ago and was started by me. There you'll find enough information to be able to do the same check that makepkg does so you can find *exactly* why it complains.
If I find the time to take a closer look myself, is there a PKGBUILD available already that I can use? Where?
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
If you would like to, http://aur.archlinux.org/packages.php?ID=22993 I will check out the archives. Thanks P.S. I searched Google last night and somebody stated to do something like "grep -R $srcdir $pkgdir"
I used Google to search the ML with your email and name and subjects(not all in one sentence) $srcdir, references, and cmake, though I couldn't find it
Though I just found in another mailing-list about the issue. The ML stated to do grep -R "(pwd)/src" pkg/ in the directory where the PKGBUILD is at. I did that and grep returned nothing. So maybe my package is alright?
On Fri, Aug 27, 2010 at 07:27, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 1:24 AM, Magnus Therning <magnus@therning.org>wrote:
On 27/08/10 06:03, Nathan O wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at this second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
The fix for the $srcdir issue depends on the nature of the issue. Not very helpful, I know. Have a look in the ml archives for a discussion of this issue, it took place not so long ago and was started by me. There you'll find enough information to be able to do the same check that makepkg does so you can find *exactly* why it complains.
If I find the time to take a closer look myself, is there a PKGBUILD available already that I can use? Where?
If you would like to, http://aur.archlinux.org/packages.php?ID=22993 I will check out the archives. Thanks
I had a quick look. I don't get any complaints about RPATH, what did you run to see that? (I should probably mention that I'm on an x86_64 system, not sure if that makes a difference though.)
P.S. I searched Google last night and somebody stated to do something like "grep -R $srcdir $pkgdir"
Yes, that's the one. The only result I get is from fqterm.bin. It looks like it contains references to the location of the source files used during the build. My uninformed guess is that it's related to some event mechanism (close by are strings like "httpDone", "windowmgr.currentChanged"...). I don't program much in C++, and I haven't used QT since about KDE 0.2 time, but my guess would be that these references to $srcdir are harmless. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Fri, Aug 27, 2010 at 2:28 AM, Magnus Therning <magnus@therning.org>wrote:
On Fri, Aug 27, 2010 at 1:24 AM, Magnus Therning <magnus@therning.org wrote:
On 27/08/10 06:03, Nathan O wrote:
I have encountered having the issues with software that uses cmake as it's build system. Usually I get the warnings stating that there is an Insecure RPATH and Package contains reference to $srcdir. I believe I figured out how to fix the RPATH issue, because a previous package had Rpath issues and I used sed to add a setting(can't remember what the setting is called at this second). The issue I have now is the Reference to $srcdir, for the current package and future reference, how do you fix it?
The fix for the $srcdir issue depends on the nature of the issue. Not very helpful, I know. Have a look in the ml archives for a discussion of
On Fri, Aug 27, 2010 at 07:27, Nathan O <ndowens.aur@gmail.com> wrote: this
issue, it took place not so long ago and was started by me. There you'll find enough information to be able to do the same check that makepkg does so you can find *exactly* why it complains.
If I find the time to take a closer look myself, is there a PKGBUILD available already that I can use? Where?
If you would like to, http://aur.archlinux.org/packages.php?ID=22993 I will check out the archives. Thanks
I had a quick look. I don't get any complaints about RPATH, what did you run to see that?
(I should probably mention that I'm on an x86_64 system, not sure if that makes a difference though.)
P.S. I searched Google last night and somebody stated to do something like "grep -R $srcdir $pkgdir"
Yes, that's the one. The only result I get is from fqterm.bin. It looks like it contains references to the location of the source files used during the build. My uninformed guess is that it's related to some event mechanism (close by are strings like "httpDone", "windowmgr.currentChanged"...). I don't program much in C++, and I haven't used QT since about KDE 0.2 time, but my guess would be that these references to $srcdir are harmless.
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
That is weird that you got grep to tell you which file(s) it was, when mine pointed nothing out to me.
On Fri, Aug 27, 2010 at 08:30, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:28 AM, Magnus Therning <magnus@therning.org>wrote: [...] That is weird that you got grep to tell you which file(s) it was, when mine pointed nothing out to me.
Indeed. This is what I see: % grep -R $(pwd)/src pkg Binary file pkg/usr/bin/fqterm.bin matches I'm not sure if the dollar-sign was lost in your earlier email, but it is required to get the expected result. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Fri, Aug 27, 2010 at 2:41 AM, Magnus Therning <magnus@therning.org>wrote:
On Fri, Aug 27, 2010 at 08:30, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:28 AM, Magnus Therning <magnus@therning.org wrote: [...] That is weird that you got grep to tell you which file(s) it was, when mine pointed nothing out to me.
Indeed. This is what I see:
% grep -R $(pwd)/src pkg Binary file pkg/usr/bin/fqterm.bin matches
I'm not sure if the dollar-sign was lost in your earlier email, but it is required to get the expected result.
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Tried it exactly how you typed it as well, and nothing again
On Fri, Aug 27, 2010 at 08:44, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:41 AM, Magnus Therning <magnus@therning.org>wrote:
On Fri, Aug 27, 2010 at 08:30, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:28 AM, Magnus Therning <magnus@therning.org wrote: [...] That is weird that you got grep to tell you which file(s) it was, when mine pointed nothing out to me.
Indeed. This is what I see:
% grep -R $(pwd)/src pkg Binary file pkg/usr/bin/fqterm.bin matches
I'm not sure if the dollar-sign was lost in your earlier email, but it is required to get the expected result.
Tried it exactly how you typed it as well, and nothing again
Fascinating! Computers, eh? ;-) Anyway, if you are happy with my cheerful hand-waving of an explanation in the earlier email then just disregard the warning from pacman for now. Otherwise seek out someone who's more knowledgeable about QT and ask them. That's pretty much the only advice I can give. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Fri, Aug 27, 2010 at 2:50 AM, Magnus Therning <magnus@therning.org>wrote:
On Fri, Aug 27, 2010 at 08:44, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:41 AM, Magnus Therning <magnus@therning.org wrote:
On Fri, Aug 27, 2010 at 08:30, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:28 AM, Magnus Therning <magnus@therning.org wrote: [...] That is weird that you got grep to tell you which file(s) it was, when mine pointed nothing out to me.
Indeed. This is what I see:
% grep -R $(pwd)/src pkg Binary file pkg/usr/bin/fqterm.bin matches
I'm not sure if the dollar-sign was lost in your earlier email, but it is required to get the expected result.
Tried it exactly how you typed it as well, and nothing again
Fascinating! Computers, eh? ;-)
Anyway, if you are happy with my cheerful hand-waving of an explanation in the earlier email then just disregard the warning from pacman for now. Otherwise seek out someone who's more knowledgeable about QT and ask them. That's pretty much the only advice I can give.
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
I uploaded the version that gave the warning before, since I can't reproduce what result you got.
On 27 August 2010 15:55, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:50 AM, Magnus Therning <magnus@therning.org>wrote:
On Fri, Aug 27, 2010 at 08:44, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:41 AM, Magnus Therning <magnus@therning.org wrote:
On Fri, Aug 27, 2010 at 08:30, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 2:28 AM, Magnus Therning <magnus@therning.org wrote: [...] That is weird that you got grep to tell you which file(s) it was, when mine pointed nothing out to me.
Indeed. This is what I see:
% grep -R $(pwd)/src pkg Binary file pkg/usr/bin/fqterm.bin matches
I'm not sure if the dollar-sign was lost in your earlier email, but it is required to get the expected result.
Tried it exactly how you typed it as well, and nothing again
Fascinating! Computers, eh? ;-)
Anyway, if you are happy with my cheerful hand-waving of an explanation in the earlier email then just disregard the warning from pacman for now. Otherwise seek out someone who's more knowledgeable about QT and ask them. That's pretty much the only advice I can give.
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
I uploaded the version that gave the warning before, since I can't reproduce what result you got.
Hi Nathan That PKGBUILD is broken and bails. You don't need to move stuff around so much if the build system is unified (configure/cmake/make/scons/waf). You can use this PKGBUILD instead: http://paste.pocoo.org/show/255008/ Notice that there is a "ccmake ." (note the dot) - that is just for your reference as a package maintainer (press C and then G to finalize). Use it to verify that all variables are correct, and what else is available to configure. As such, patching a cmake-based build system is incorrect; you simply configure with the options and prepend "-D", i.e if you need to set RPATH off (you _don't_ need that with this package): cmake . -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_SKIP_RPATH=ON You can have it all on one line, doesn't matter (styling issue). Also, the reference to $srcdir is within a binary, which is OK 90% of the time. If you notice weird mentions of the build directory at runtime, you need to report it upstream. This is my output: [schiv@v3000 fqterm]$ grep -R "$(pwd)/src" pkg/ Binary file pkg/usr/bin/fqterm.bin matches The use of quotes (" ") on variables and commands; use them whenever there is possibility of reference to something with whitespace(s), like a path (and paths can have spaces, especially when makepkg can be run by a user from any dir). That's why when you see buildscripts of some people or community (for eg. Gentoo ebuilds) they have standardised the following for the sake of consistency: "${foobar}" The braces ({ }) allow escaping run-together words as variables, i.e $foo_$bar won't work, you have to use ${foo}_$bar. -- GPG/PGP ID: B42DDCAD
Am 27.08.2010 13:08, schrieb Ray Rashif:
cmake . -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_SKIP_RPATH=ON
Also build the release version with '-DCMAKE_BUILD_TYPE=Release', because otherwise the binary contains references to the source code so that gdb finds the source files. Regards, Bernhard
On Fri, Aug 27, 2010 at 6:43 AM, Bernhard Walle <bernhard@bwalle.de> wrote:
Am 27.08.2010 13:08, schrieb Ray Rashif:
cmake . -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_SKIP_RPATH=ON
Also build the release version with '-DCMAKE_BUILD_TYPE=Release', because otherwise the binary contains references to the source code so that gdb finds the source files.
Regards, Bernhard
Thank you all for the tips, I simily prefer the ./configure and make system :D, never had very much experience with cmake
On Sat, Aug 28, 2010 at 12:18 AM, Nathan O <ndowens.aur@gmail.com> wrote:
On Fri, Aug 27, 2010 at 6:43 AM, Bernhard Walle <bernhard@bwalle.de>wrote:
Am 27.08.2010 13:08, schrieb Ray Rashif:
cmake . -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_SKIP_RPATH=ON
Also build the release version with '-DCMAKE_BUILD_TYPE=Release', because otherwise the binary contains references to the source code so that gdb finds the source files.
Regards, Bernhard
Thank you all for the tips, I simily prefer the ./configure and make system :D, never had very much experience with cmake
I put cmake . -DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_SKIP_RPATH=ON \ -DCMAKE_BUILD_TYPE=Release
install -d ${pkgdir}/usr/{bin,share/{applications,pixmaps,${pkgname}}} make DESTDIR="${pkgdir}" install install -m644 res/pic/${pkgname}.png ${pkgdir}/usr/share/pixmaps/${pkgname}.png install -Dm644 ${srcdir}/${pkgname}.desktop ${pkgdir}/usr/share/applications/${pkgname}.desktop
Still says that grep -R $(pwd)/src pkg/
Binary file pkg/usr/bin/fqterm.bin matches
Am 28.08.10 07:30, schrieb Nathan O:
Still says that grep -R $(pwd)/src pkg/
Binary file pkg/usr/bin/fqterm.bin matches
Could you search for the string in a text editor (one that has no problem with binary files like vim) or just use 'strings' and tell us in which context the string occurs? Maybe then we have an idea how to get rid of it. :) Regards, Bernhard
t On Sat, Aug 28, 2010 at 1:27 AM, Bernhard Walle <bernhard@bwalle.de> wrote:
Am 28.08.10 07:30, schrieb Nathan O:
Still says that grep -R $(pwd)/src pkg/
Binary file pkg/usr/bin/fqterm.bin matches
Could you search for the string in a text editor (one that has no problem with binary files like vim) or just use 'strings' and tell us in which context the string occurs? Maybe then we have an idea how to get rid of it. :)
Regards, Bernhard
When I do strings /usr/bin/fqterm.bin I see http://aur.pastebin.com/FQ3wrRNV
Am 28.08.2010 08:44, schrieb Nathan O:
When I do strings /usr/bin/fqterm.bin I see http://aur.pastebin.com/FQ3wrRNV
Without the context, that information is more or less useless. Could you upload the complete binary somewhere? Or everything we need to rebuild the package (PKGBUILD, tarball / URL, ...)? Regards, Bernhard
On Sat, Aug 28, 2010 at 5:55 AM, Bernhard Walle <bernhard@bwalle.de> wrote:
Am 28.08.2010 08:44, schrieb Nathan O:
When I do strings /usr/bin/fqterm.bin I see http://aur.pastebin.com/FQ3wrRNV
Without the context, that information is more or less useless. Could you upload the complete binary somewhere? Or everything we need to rebuild the package (PKGBUILD, tarball / URL, ...)?
Regards, Bernhard
Here is the pkg file: http://www.mediafire.com/file/of1b1v48rlwkn72/fqterm-0.9.6.8-2-i686.pkg.tar....
Hi, Am 28.08.2010 19:17, schrieb Nathan O:
Here is the pkg file:
http://www.mediafire.com/file/of1b1v48rlwkn72/fqterm-0.9.6.8-2-i686.pkg.tar....
Ok, I took a look at the project. The problem is that the source code uses __FILE__ and gcc uses the full path of __FILE__ if not called in the same directory. So gcc -c bla.c # (1) produces __FILE__ as 'bla.c' while gcc -o /home/bwalle/bla.o /home/bwalle/bla.c # (2) produces __FILE__ as '/home/bwalle/bla.c'. Since the build system uses a main CMakeLists.txt instead of split CMakeLists.txt in the source files gcc gets called the way (1). I would just ignore the warning, but if you really care, you chould change the build system. Or simply replace __FILE__ by "". HTH. Regards, Bernhard
participants (4)
-
Bernhard Walle
-
Magnus Therning
-
Nathan O
-
Ray Rashif