Solved [Solved] librcc update problem

H

Hanky-panky

Guest
Code: 
rccdb4.c: In function 'rccDb4InitContext':
rccdb4.c:112: error: 'stmp' undeclared (first use in this function)
rccdb4.c:112: error: (Each undeclared identifier is reported only once
rccdb4.c:112: error: for each function it appears in.)
gmake[2]: *** [rccdb4.lo] Errore 1
gmake[2]: Leaving directory `/usr/ports/devel/librcc/work/librcc-0.2.12/src'
gmake[1]: *** [all-recursive] Errore 1
gmake[1]: Leaving directory `/usr/ports/devel/librcc/work/librcc-0.2.12'
gmake: *** [all] Errore 2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** [do-build] Error code 1
Also set MAKE_JOBS_UNSAFE=yes doesn't help.

Any idea?
 
Re: librcc update problem

PS: this is a VLC dependency needed to compile or upgrade VLC, so I need a fix.
 
Re: librcc update problem

Hanky-panky said:
Also set MAKE_JOBS_UNSAFE=yes doesn't help.
Click to expand...
Have you tried putting
Code: 
MAKE_JOBS_UNSAFE=yes
in your /etc/make.conf (note there's no set there)?
 
Re: librcc update problem

The MAKE_JOBS_UNSAFE setting rarely helps. It is in the default error message when something goes wrong and very often it is misleading when the build fails because of a genuine compilation problem that is not caused by concurrent use of multiple make(1) jobs.
 
Re: librcc update problem

kpa said:
The MAKE_JOBS_UNSAFE setting rarely helps.
Click to expand...
No offence, but my experience is quite different: MAKE_JOBS_UNSAFE has fixed problems for me on several occasions. The YMMV principle applies, I suppose.
 
Re: librcc update problem

It never ever fixed anything for me good brother and surely not this time. I wrote to the developer but he never ever replied.
 
Re: librcc update problem

Hanky-panky said:
PS: this is a VLC dependency needed to compile or upgrade VLC, so I need a fix.
Click to expand...
I must admit, though, that upgrading VLC went OK even with librcc left without this last update that fails. The older installed version was fine, no complaints.
 
Re: librcc update problem

I have to say the ex maintainer was kind enough to reply to my inquiry. Considering I'm away from that FreeBSD machine with the librcc compile problem for like a week, to help, I will forward his helpful reply on here:

Hey,

I'm no longer the maintainer of librcc, adding fluffy@FreeBSD.org.

For me, librcc still builds fine on 9.1 and 10.0, when did this stop
working for you?


Looking at the source, it seems that DB_VERSION_MISMATCH is set for me,
so that stmp array will be declared correctly. I find no mention of this
though, very weird.

Ah, what does the configure stage say for you? Mine ends with:

Configuration:
POSIX Threading Support: yes

External IConv Library: yes
LibCharset Library: yes

Dynamic Engine Loading Support: yes
Enca Charset Detection Support: yes
LibRCD Charset Detection Support: yes
LibGUESS Charset Detection Support: no

Multilanguage support with DB4: no
Language autodetection using aspell: yes
Libtranslate support: no
Libtranslate Timed Translate: no

User Interfaces:
GTK User Interface: no
GTK2 User Interface: no
GTK3 User Interface: no

Directories:
RCC Data Directory: /usr/local/lib/rcc/


On Wed, 2013-12-11 at 12:08:54 -0800, wrote:
> Hi
>
>
> Even with make jobs unsafe here the error:
>
>
> libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -DLIBRCC_DATA_DIR=\
> "/usr/local/lib/rcc/\" -I/usr/local/include/libxml2 -I/usr/local/include -I/usr
> /local/include -I/usr/local/include/db41 -O2 -pipe -fno-strict-aliasing -std=
> gnu89 -Wall -Wpointer-arith -I/usr/local/include -MT rccenca.lo -MD -MP -MF
> .deps/rccenca.Tpo -c rccenca.c -fPIC -DPIC -o .libs/rccenca.o
> libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -DLIBRCC_DATA_DIR=\
> "/usr/local/lib/rcc/\" -I/usr/local/include/libxml2 -I/usr/local/include -I/usr
> /local/include -I/usr/local/include/db41 -O2 -pipe -fno-strict-aliasing -std=
> gnu89 -Wall -Wpointer-arith -I/usr/local/include -MT rccenca.lo -MD -MP -MF
> .deps/rccenca.Tpo -c rccenca.c -o rccenca.o >/dev/null 2>&1
> if /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I..
> -I../src -DLIBRCC_DATA_DIR=\"/usr/local/lib/rcc/\" `xml2-config --cflags`
> -I/usr/local/include -I/usr/local/include/db41 -O2 -pipe -fno-strict-aliasing
> -std=gnu89 -Wall -Wpointer-arith -I/usr/local/include -MT rccdb4.lo -MD -MP -MF
> ".deps/rccdb4.Tpo" -c -o rccdb4.lo rccdb4.c; \
> then mv -f ".deps/rccdb4.Tpo" ".deps/rccdb4.Plo"; else rm -f ".deps/
> rccdb4.Tpo"; exit 1; fi
> libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -DLIBRCC_DATA_DIR=\
> "/usr/local/lib/rcc/\" -I/usr/local/include/libxml2 -I/usr/local/include -I/usr
> /local/include -I/usr/local/include/db41 -O2 -pipe -fno-strict-aliasing -std=
> gnu89 -Wall -Wpointer-arith -I/usr/local/include -MT rccdb4.lo -MD -MP -MF
> .deps/rccdb4.Tpo -c rccdb4.c -fPIC -DPIC -o .libs/rccdb4.o
> rccdb4.c: In function 'rccDb4InitContext':
> rccdb4.c:112: error: 'stmp' undeclared (first use in this function)
> rccdb4.c:112: error: (Each undeclared identifier is reported only once
> rccdb4.c:112: error: for each function it appears in.)
> gmake[2]: *** [rccdb4.lo] Errore 1
> gmake[2]: Leaving directory `/usr/ports/devel/librcc/work/librcc-0.2.12/src'
> gmake[1]: *** [all-recursive] Errore 1
> gmake[1]: Leaving directory `/usr/ports/devel/librcc/work/librcc-0.2.12'
> gmake: *** [all] Errore 2
> ===> Compilation failed unexpectedly.
>
> *** [do-build] Error code 1
>
> Stop in /usr/ports/devel/librcc.
> *** [build] Error code 1
>
> Stop in /usr/ports/devel/librcc.
> ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/
> portupgrade20131211-64033-19ww80m env UPGRADE_TOOL=portupgrade UPGRADE_PORT=
> librcc-0.2.9_6 UPGRADE_PORT_VER=0.2.9_6 make
> ** Fix the problem and try again.
> ** Listing the failed packages (-:ignored / *:skipped / !:failed)
> ! devel/librcc (librcc-0.2.9_6) (compiler error)
>
> ------------------------------
>
> Exactly same error on three different systems.
>
Click to expand...
Like you brothers can see, he was nice putting a new maintainer in the CC. I still haven't heard from this new maintainer with such an amusing nick (fluffy brother, I'm sure we could get along well considering our nicks). I hope he will follow up and fix this problem soon.
 
Re: librcc update problem

free-and-bsd said:
Hanky-panky said:
PS: this is a VLC dependency needed to compile or upgrade VLC, so I need a fix.
Click to expand...
I must admit, though, that upgrading VLC went OK even with librcc left without this last update that fails. The older installed version was fine, no complaints.
Click to expand...
Well, sure, you can do that, then I prefer to do it with every dependencies upgrades in place.
 
Re: librcc update problem

Hanky-panky said:
Looking at the source, it seems that DB_VERSION_MISMATCH is set for me,
so that stmp array will be declared correctly. I find no mention of this
though, very weird.
Click to expand...
The code in question is:
Code: 
#ifdef DB_VERSION_MISMATCH
    char stmp[160];
#endif /* DB_VERSION_MISMATCH */
Now in the work/librcc* directory DB_VERSION_MISMATCH is only found in the file src/rccdb4.c. I tried also grep -r DB_VERSION_MISMATCH for both /usr/include and /usr/local/include with no result. Which means, if I understand things correctly, DB_VERSION_MISMATCH is NOT defined and char stmp[160] goes undeclared.
 
Re: librcc update problem

So, given the above, it may be changed from #ifdef to #ifndef form:
Code: 
#ifndef DB_VERSION_MISMATCH
#define DB_VERSION_MISMATCH
    char stmp[160];
#endif /* DB_VERSION_MISMATCH */
This way it compiles OK. Or should DB_VERSION_MISMATCH be somehow defined in /etc/make.conf?
 
Re: librcc update problem

Thankx Thanks to the new maintainer, the good brother fluffy.

The problem, as he admitted, was partly his fault (because like it said he didn't put a version check in the code) and partly the outdated DB Berkeley database in my installation from my side.

Now you can see in UPDATING FreeBSD ports management officially pointed to the problem inviting the users to update their DB Berkeley database at least to version 4.8. Here's what fluffy@freebsd.org (Dima Panov) said in the mail he sent to me:

Hello!

As I understand, you tried to build librcc with enabled BDB option
againist outdated BerkekeyDB release (4.1/4.2?).

Really, it was my fault to miss minimum version check. db43 is minimum
supported version.

However, current ports state marks all outdated bdb verions as
deprecated, and migration to db5 is strongly recommended.
Click to expand...

Consequently to this incident, they updated the file /usr/ports/UPDATING like this:

Code: 
20131214:
  AFFECTS: users of databases/db4*
  AUTHOR: mandree@FreeBSD.org

  Berkeley DB versions before and excluding 4.8 have been marked
  deprecated.  Please see https://wiki.freebsd.org/Ports/BerkeleyDBCleanup
  for upgrade instructions.

  You can add WITH_BDB_VERSION=5 or WITH_BDB_VERSION=6 to have all
  applications that get rebuilt use Oracle Berkeley DB 5 or 6, respectively.

  Note that Oracle Berkeley DB 6 is under the more restrictive Affero GPL v3.
Thankx Thanks brother Dima, everything has been solved. Thank you to the maintainers in this case more than to the community (yes, it appears we are a lot dumber and less smart compared to maintainers :(). Is this normal?
 
Re: librcc update problem

Hanky-panky said:
...yes, it appears we are a lot more dumb and less smart compared to maintainers...
Click to expand...
I, personally, don't think so about myself, at least.

Since one normally expects the port's configure scripts to check for such things as dependency packages' versions, you usually only check the /usr/ports/UPDATING for things concerning the installed ports marked for updating -- devel/librcc in our case.

So, as end-user (as different from maintainer) I expect either of the two: (1) portmaster to mark Berkeley DB for upgrading as a dependency or (2) devel/librcc port build scripts to (at least) signal the outdated version of a dependency package.

This seems to be logical, too, or else I'd have to know every single package out of the several hundreds installed on the system, including their versions and dependencies. Or did YOU personally install that Berkeley DB on your system? I bet it was installed as a dependency without you ever caring about its version. At least, the ports managing system is carefully built to make this process as easy as that.

OK, I hope I've convinced you that you are not more dumb than the maintainers are :)
 
Re: librcc update problem

Hanky-panky said:
(yes, it appears we are a lot dumber and less smart compared to maintainers :(). Is this normal?
Click to expand...
Actually, there's quite a bit of overlap. Anyone who's confident enough that they can take care of certain ports can be a maintainer and several people here (and elsewhere in the community) maintain ports indeed. Even yours truly maintains a few. However, FWIW I do get the impression that the larger and/or more complicated ports are more often maintained by (former or current) FreeBSD developers.
 
Re: librcc update problem

Hanky-panky said:
Thankx
Now you can see in UPDATING FreeBSD ports management officially pointed to the problem inviting the users to update their DB Berkeley database at least to version 4.8.
Click to expand...
No they DID NOT. At the time when this problem happened /usr/ports/UDATING didn't contain the text you're quoting in your post -- I carefully checked that. It appears only now, after I've fetched and updated the ports tree.
 
Re: librcc update problem

Hanky-panky said:
everything has been solved...
Click to expand...
Would you mind sharing, please, HOW you solved this? I mean, how did you upgrade your Berkeley DB in a secure way? The reference pages linked in the UPDATING file are too unclear to follow: I have NO IDEA which applications are using the installed version of Berkeley DB and which databases they've created.
 
Re: librcc update problem

free-and-bsd said:
Hanky-panky said:
everything has been solved...
Click to expand...
Would you mind sharing, please, HOW you solved this? I mean, how did you upgrade your Berkeley DB in a secure way? The reference pages linked in the UPDATING file are too unclear to follow: I have NO IDEA which applications are using the installed version of Berkeley DB and which databases they've created.
Click to expand...
If you read his e-mail to me you can see he admitted he missed a version check. He surely will come up with an update taking care of it in the near future.

For the upgrading process, in UPDATING you always find the solution: https://wiki.freebsd.org/Ports/BerkeleyDBCleanup.
 
Re: librcc update problem

fonz said:
Hanky-panky said:
(yes, it appears we are a lot dumber and less smart compared to maintainers :(). Is this normal?
Click to expand...
Actually, there's quite a bit of overlap. Anyone who's confident enough that they can take care of certain ports can be a maintainer and several people here (and elsewhere in the community) maintain ports indeed. Even yours truly maintains a few. However, FWIW I do get the impression that the larger and/or more complicated ports are more often maintained by (former or current) FreeBSD developers.
Click to expand...
Overall, I'm very satisfied with the "service" maintainers offered to me in this particular case. I'm not equally happy about the service offered by the community related to an old question I posted in the past.

I have the idea these maintainers not only are really competent, they are also very nice. They both reply within hours to my inquiry with solutions, totally no harsh comments, no arrogance at all, all those things often I read on this forum. I have to say - even if I do administer some FreeBSD machines - I just come here when I do have a problem and I do not figure how to resolve it myself. The few experiences I had in the past do not encourage me to come here more often.

It seems these guys maintaining and developing FreeBSD do not come here, maybe because of the same complaint I said above (my guess, nothing more nothing less). Then they are happy and helpful guys really incarnating the spirit of a top class free OS and they support it and its users at their best.

It wasn't the first time I contacted them, it happened like ten times, and ALWAYS I had my friendly and resolutive replies.

Peace, good brothers, peace.
 
Re: librcc update problem

Hanky-panky said:
free-and-bsd said:
Hanky-panky said:
For upgrading process, in UPDATING you always find the solution:

https://wiki.freebsd.org/Ports/BerkeleyDBCleanup
Click to expand...
Click to expand...
Click to expand...
I sure have followed that link and read the document when I first found it in your reply, but thanks for the pointer anyway :).

Now there are some 20+ ports that use, for example, databases/db41. I have, quite frankly, no idea which databases they create and how they use them. The document in question mentions certain complicated manipulations with those databases assuming the user knows all about them. So I was just wondering: if you yourself have solved this problem by, presumably, following that document and upgrading to databases/db5, then how exactly did you solve this problem?

Or do you mean it is "solved", assuming that the maintainer will include the needed changes in the near future?

Don't get me wrong, just the thread is marked [SOLVED] and I want to make sure what the exact answer is, since I also have this problem and am interested in the solution. Granted, I'm not expected to start a new thread, am I? ;)
 
You must log in or register to reply here.
Back
Top