18 Jun
2012
18 Jun
'12
3:45 p.m.
I notice in my kcrash backtrace captures that sometimes I see references to files in
"dev/shm." That is the location for tmpfs/$TMP on my system, where I build
packages.
Are those "dev/shm" references normal or am I doing something wrong with
creating my debugging symbol packages?
Thanks much.
Darrell
18 Jun
18 Jun
6:45 p.m.
New subject: [trinity-devel] Suspect debugging symbols
On Mon, 18 Jun 2012 08:45:59 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I notice in my kcrash backtrace captures that
sometimes I see
references to files in "dev/shm." That is the location for tmpfs/$TMP
on my system, where I build packages.
Are those "dev/shm" references normal or am I doing something wrong
with creating my debugging symbol packages?
It could be rpath references. Last time I built Trinity Qt3 (for
3.5.13) my Qt3 package was f*cked up with /tmp/* rpaths.
Thanks much.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
7:05 p.m.
New subject: [trinity-devel] Suspect debugging symbols
I notice in my
kcrash backtrace captures that sometimes I see
references to files in "dev/shm." That is the location for tmpfs/$TMP
on my system, where I build packages.
Are those "dev/shm" references normal or am I doing something wrong
with creating my debugging symbol packages?
It could be rpath references. Last time I built Trinity Qt3
(for 3.5.13) my Qt3 package was f*cked up with /tmp/* rpaths.
7:34 p.m.
New subject: [trinity-devel] Suspect debugging symbols
Are those "dev/shm" references normal or am
I doing something wrong
with creating my debugging symbol packages?
It could be rpath references. Last time I built Trinity Qt3
(for 3.5.13) my Qt3 package was f*cked up with /tmp/*
8:04 p.m.
New subject: [trinity-devel] Suspect debugging symbols
On Mon, 18 Jun 2012 12:34:24 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
rpaths.
Thanks. Does that mean I should build all packages with
rpath explicitly disabled?
cmake:
-DCMAKE_SKIP_RPATH=OFF
automake:
--disable-rpath
By the way, in all of my Trinity builds I set
LD_LIBRARY_PATH=/opt/trinity/lib:/opt/trinity/lib/trinity. Does that
make a difference?
These paths are the ones for the final packages. They should be added
to /etc/ld.so.conf, and I think the install script of the package
every other one needs (so I suppose it's qt3/tqt3) is a good place to
do that.
If you choose that way, don't forget to take account of the lib->lib64
transformation when 64-bit packages are built; you can take the Qt3
build script of KDE 3.5.10 for Slackware 13.0 as an example.
(for $trinityprefix/lib{,64} your (T)Qt3 build script perhaps already
does that)
Are those
"dev/shm" references normal or am I doing something
wrong with creating my debugging symbol packages?
It could be rpath references. Last time I built Trinity Qt3
(for 3.5.13) my Qt3 package was f*cked up with /tmp/*
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:16 p.m.
New subject: [trinity-devel] Suspect debugging symbols
By the way, in
all of my Trinity builds I set
LD_LIBRARY_PATH=/opt/trinity/lib:/opt/trinity/lib/trinity.
Does that make a difference?
These paths are the ones for the final packages. They should
be added to /etc/ld.so.conf, and I think the install script of the
package every other one needs (so I suppose it's qt3/tqt3) is a good
place to do that.
If you choose that way, don't forget to take account of the
lib->lib64 transformation when 64-bit packages are built; you can take
the Qt3 build script of KDE 3.5.10 for Slackware 13.0 as an
example. (for $trinityprefix/lib{,64} your (T)Qt3 build script
perhaps already does that)
7:52 p.m.
New subject: [trinity-devel] Suspect debugging symbols
On Mon, 18 Jun 2012 12:05:03 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Thanks. Does that mean I should build all packages with rpath
explicitly disabled?
cmake:
-DCMAKE_SKIP_RPATH=OFF
automake:
--disable-rpath
IIRC I had this problem only for Qt3. Because of the unusual build
system you could have to manually remove rpath:
http://wiki.debian.org/RpathIssue
Removing the rpath after build has the advantage that the RPATH-enabled
uic and moc ease the compilation of moc/uic-dependent parts of Qt.
If you want to build without rpath, you will have to either specify
LD_LIBRARY_PATH in your build script or build the package where it is
intended to be installed (and it is what Slackware does for Qt3 and
Qt4).
I notice in my kcrash backtrace captures that
sometimes I see
references to files in "dev/shm." That is the location for
tmpfs/$TMP on my system, where I build packages.
Are those "dev/shm" references normal or am I doing something
wrong with creating my debugging symbol packages?
It could be rpath references. Last time I built Trinity Qt3
(for 3.5.13) my Qt3 package was f*cked up with /tmp/* rpaths.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:13 p.m.
New subject: [trinity-devel] Suspect debugging symbols
IIRC I had this problem only for Qt3. Because of the
unusual
build system you could have to manually remove rpath:
http://wiki.debian.org/RpathIssue
Removing the rpath after build has the advantage that the
RPATH-enabled uic and moc ease the compilation of moc/uic-dependent parts
of Qt.
How do I remove rpath after the build?
Second, I am build separate debugging symbol packages. Could that be related?
If you want to build without rpath, you will have to
either
specify LD_LIBRARY_PATH in your build script or build the package
where it is intended to be installed (and it is what Slackware does for
Qt3 and Qt4).
In my Trinity builds I have been explicitly setting
LD_LIBRARY_PATH=/opt/trinity/lib;/opt/trinity/lib/trinity. Should I stop doing that?
I'm trying to get my mind right about this. :-)
In my build logs sometimes I see something similar to this:
-rpath /opt/trinity/lib
Sometimes I see similar to this:
--rpath -Wl,/dev/shm/gwenview/src/gvcore/.libs -Wl,--rpath -Wl,/opt/trinity/lib
-L/opt/trinity/lib
Darrell
4601
days inactive
4601
days old
7 comments
2 participants
participants (2)
-
/dev/ammo42 -
Darrell Anderson