Xffm4 (Rodent/xffm+) / Bugs / #56 Wrong LIBDIR definition

Edscott Wilson Garcia - 2014-02-07

status: open --> accepted
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-07

Now fixed in GIT repository. LIBDIR is where rfm/plugins will be placed and loaded from.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Antonio Trande - 2014-02-07

I've tried 83f411 git release. This is log: http://www.fpaste.org/75393/

Just to provide documentary evidence in this thread, I obtain this error:

...
In file included from ../src/rfm-diff.c:47:0:
../src/rfm-diff-misc.i: In function 'get_rcfile':
../src/rfm-diff-misc.i:54:38: error: 'USER_RFM_DIR' undeclared (first use in this function)
gchar *rcdir = g_build_filename (USER_RFM_DIR, NULL);
^
../src/rfm-diff-misc.i:54:38: note: each undeclared identifier is reported only once for each function it appears in

While DLIBDIR is still -DLIBDIR=\"/usr/lib\"

Last edit: Antonio Trande 2014-02-07

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-08

I see. --libdir is not being passed down from top level configure to nested configures. I have not come up with a reasonable solution yet, but I'll work on it this weekend.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-08

I've now fixed the problem with arguments not being passed down to nested configures and updated GIT repository. My rpmbuild -ba on OpenSUSE proceeds almost to the end, but does not complete (yet). Seems like I have not correctly defined the translation files or something like that.

About the USER_RFM_DIR error, you must update to the latest git version of librfm for that to go away.

Options --enable-libzip --with-gtk2 are no longer used in rodent. The Gtk version is determined from librfm as well as libzip compatibility.

I'll keep checking rpmbuild in OpenSUSE.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-09

Rpm now builds in OpenSUSE
No errors with rpmlint, but I'll look into these warnings.

/bin/bash rpmlint rodent-5.2.4-1.x86_64.rpm
rodent.x86_64: W: name-repeated-in-summary C Rodent
rodent.x86_64: W: conflicts-with-provides fgr
rodent.x86_64: W: conflicts-with-provides rodent-diff
rodent.x86_64: W: conflicts-with-provides rodent-fgr
rodent.x86_64: W: conflicts-with-provides rodent-fm
rodent.x86_64: W: conflicts-with-provides rodent-iconmgr
rodent.x86_64: W: package-with-huge-translation 70%
1 packages and 0 specfiles checked; 0 errors, 7 warnings.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Antonio Trande - 2014-02-09
  
  Rpm now builds in OpenSUSE
  
  It's okay for me too.
  
  librfm: http://koji.fedoraproject.org/koji/taskinfo?taskID=6509164
  rodent: http://koji.fedoraproject.org/koji/taskinfo?taskID=6509248
  
  'conflicts-with-provides' warnings are caused by conflicts between 'Provides:' and 'Conflicts:' calls; they have same arguments.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-19

status: accepted --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Antonio Trande - 2014-02-19

-DLIBDIR set as /usr/lib in a x86_64 system even if configure calls for
--libdir=/usr/lib64 .

Same issue in librfm-5.2.4 for -DRFM_MODULE_DIR. Following an example:

gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../primary -I/usr/include/dbh -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -DLIBDIR=\"/usr/lib64\" -DRFM_MODULE_DIR=\"/usr/lib/rfm/rmodules\" -DPACKAGE_DATA_DIR=\""/usr/share"\" -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -DPACKAGE_ICON_DIR=\"""\" -I../../rodent -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o librodent_la-rodent_expose.lo test -f '../../rodent/rodent_expose.c' || echo './'../../rodent/rodent_expose.c

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-19

status: closed-fixed --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edscott Wilson Garcia - 2014-02-19

Hmm. I thought I had that fixed.
I've removed release 5.2.4 for librfm and put out release 5.2.5 which fixes the issue. If you want to generate a spec file from configure, you should configure with the appropriate --libdir option now (and --with-centos for CentOS instead of OpenSUSE).

My OpenSUSE rpm gives me this warning with rpmlint, even though the spec file has an instruction to strip the file. Don´t know why.

librfm5.x86_64: W: unstripped-binary-or-object /usr/lib64/librodent.so.2.0.0

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Antonio Trande - 2014-02-19
  
  I've removed release 5.2.4 for librfm and put out release 5.2.5 which >fixes the issue. If you want to generate a spec file from configure, you >should configure with the appropriate --libdir option now (and --with-
  centos for CentOS instead of OpenSUSE).
  
  It's okay now.
  
  librfm5.x86_64: W: unstripped-binary-or-object /usr/lib64
  /librodent.so.2.0.0
  
  Check if it's executable.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Wrong LIBDIR definition

Basic desktop applications

Group

Searches

Help

#56 Wrong LIBDIR definition

Discussion