# Undefined symbol "opencookie"



## balanga (Feb 3, 2017)

I'm in the process of getting a web server up and running using Apache24 which I have done numerous times in the past. Apache24 has been updated to the latest version and "*It Works!"
*
Now I've just added php56 and on restarting Apache I get the following warning:


```
httpd: Syntax error on line 178 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/libphp5.so into server: /usr/local/libexec/apache24/libphp5.so: Undefined symbol "fopencookie"
```

Anyone know what this means? I have noticed tha libphp5.so is present in libexec/apache24 but it has permissions set to 444 whereas all the other modules  have 755. Is this normal?


----------



## SirDice (Feb 3, 2017)

Did you install www/mod_php56 or only lang/php56?


----------



## balanga (Feb 3, 2017)

Both.


----------



## SirDice (Feb 3, 2017)

What does `ldd /usr/local/libexec/apache24/libphp5.so` return?


----------



## ShelLuser (Feb 3, 2017)

(edit) Overlooked the answer above.

How exactly did you add PHP56?  Did you change any options in the Port?


----------



## balanga (Feb 4, 2017)

SirDice said:


> What does `ldd /usr/local/libexec/apache24/libphp5.so` return?



I can't paste it in, but it looked like you would expect showing pointers to eight libraries such as crypt, pcre, etc. Nothing unusual.


----------



## balanga (Feb 4, 2017)

ShelLuser said:


> (edit) Overlooked the answer above.
> 
> How exactly did you add PHP56?  Did you change any options in the Port?




`pkg install php56`


----------



## ShelLuser (Feb 4, 2017)

To answer your first question: yes, the 444 permissions mask is normal. As to the output SirDice asked for, maybe you can compare it to this:


```
$ ldd ./libphp5.so
./libphp5.so:
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x801a8d000)
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x801cad000)
        libm.so.5 => /lib/libm.so.5 (0x801f26000)
        libthr.so.3 => /lib/libthr.so.3 (0x80214f000)
        libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x802374000)
        libz.so.6 => /lib/libz.so.6 (0x802713000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x802929000)
        libc.so.7 => /lib/libc.so.7 (0x800821000)
```
Another thing: which FreeBSD version are you using? Any chance that you upgraded things in between?

Also: has everything been installed as a binary package, so also Apache? (`pkg install apache24`)?

Usually things like these can happen if there's an inconsistency between the packages or the base system. For example: I recently upgraded my laptop from FreeBSD 10.3 to 11.0 and as a result security/libssh2 could no longer find libssl.so.7, because it had been replaced with libssl.so.8. Of course this only applies if you compile, binary packages are usually kept up to date.


----------



## balanga (Feb 5, 2017)

ShelLuser said:


> To answer your first question: yes, the 444 permissions mask is normal. As to the output SirDice asked for, maybe you can compare it to this:
> 
> 
> ```
> ...



All the same modules are listed, but all the addresses are different. I'm not sure if that is to be expected.



> Another thing: which FreeBSD version are you using? Any chance that you upgraded things in between?
> 
> Also: has everything been installed as a binary package, so also Apache? (`pkg install apache24`)?
> 
> Usually things like these can happen if there's an inconsistency between the packages or the base system. For example: I recently upgraded my laptop from FreeBSD 10.3 to 11.0 and as a result security/libssh2 could no longer find libssl.so.7, because it had been replaced with libssl.so.8. Of course this only applies if you compile, binary packages are usually kept up to date.



I'm running FreeBSD 11.0-CURRENT which was installed almost a year ago. I haven't upgraded it. All packages were installed as binary packages and have been updated. I guess I'll try reinstalling Apache24 and php56 if I can't sort out the problem today. I have installed both on numerous occasions in the past and am not aware of doing anything differently this time.


----------



## SirDice (Feb 6, 2017)

Update to 11.0-RELEASE, 11.0-CURRENT is old and not supported any more. It's possible you're having an issue with something that was added/changed after the revision you have.


----------



## balanga (Feb 6, 2017)

SirDice said:


> Update to 11.0-RELEASE, 11.0-CURRENT is old and not supported any more. It's possible you're having an issue with something that was added/changed after the revision you have.



`freebsd-update -r 11.0-RELEASE upgrade`


```
src component not installed, skipped
Lookin up update.FREEBSD.org mirrors... 4 mirrors found.
Fetching public key from update6.freebsd.org... failed.
Fetching public key from update5.freebsd.org... failed.
Fetching public key from update4.freebsd.org... failed.
Fetching public key from update3.freebsd.org... failed.
No mirrors remaining, giving up.
```

The hosts are pingable.


?????


----------



## balanga (Feb 6, 2017)

After a little Googling, I find that `freebsd-update` only works for RELEASE versions. Still looking for a way to update from CURRENT to RELEASE.


----------



## ShelLuser (Feb 6, 2017)

Personally I'd use the source tree, but I guess you're not looking for that   Just to clarify: I mean using Subversion to check out the source code to /usr/src then compile the whole thing. I never used CURRENT myself, only RELEASE so my experience is limited.

Either way, I can't help think that this should work considering that all you're basically doing is upgrade the base system. It's been years ago but I think I once did the same thing. Either way,did you double check /etc/freebsd-update.conf?

I also noticed the posts about freebsd-update only supporting RELEASE, but considering that you're upgrading to a RELEASE version I can't help think that this should work. I'll also try some Google-fu.

Edit: `# freebsd-update -r 11.0`?  That's what I got from this thread.


----------



## SirDice (Feb 6, 2017)

ShelLuser said:


> I also noticed the posts about freebsd-update only supporting RELEASE, but considering that you're upgrading to a RELEASE version I can't help think that this should work.


It only works from one -RELEASE to another. 

The only way to upgrade -CURRENT to 11.0-RELEASE is by using the source. There's no other way. Should be relatively painless though, time consuming, yes, but easy to do.


----------



## balanga (Feb 6, 2017)

Time consuming seems like an understatement! `make buildworld` took several hours and then `make buildkernel KERNCONF=GENERIC` has been running for several more hours and has displaying 


```
ctfmerge -L VERSION -g -o kernel.full
```

for maybe three hours. Can't help thinking the process has stalled....

I followed the instructions here:-

https://freebsdrocks.net/index.php/...to-upgrade-freebsd-to-the-next-stable-version


----------



## ShelLuser (Feb 6, 2017)

balanga said:


> Time consuming seems like an understatement! `make buildworld` took several hours and then `make buildkernel KERNCONF=GENERIC` has been running for several more hours and has displaying
> 
> 
> ```
> ...


It is time consuming but it can also be extremely rewarding because this process allows you to fine tune and control just about _everything_ on your base system. Be sure to check out src.conf(5) if you're interested in this (which I guess you're not, but figured I'd mention it). I'm not only talking about optimizing your system (a little bit) but also getting rid of overhead. For example, I don't have a floppy disk in my laptop so I use WITHOUT_FLOPPY= in /etc/src.conf to ensure that floppy support is not included. I've always been a little purist (I suppose) so I've been using WITHOUT_INFO almost as long as I've been using FreeBSD to get rid of that (in my opinion) ridiculous tex info system (I never saw the added value). This option has now become obsolete because it's the default on 11.0.

Now, this is obviously totally not interesting for you, but because I keep my system up to date using the source tree I even made sure to remove stuff such as firewalls which I don't need, no PKG bootstrapping, no SVN lite, etc. It's in my opinion ideal on smaller systems as well as on server which you'd like to keep customized.

I tried checking out that website you mentioned but all I got were errors. Why not use the official documentation? Chapter 23.6 of the handbook explains most of this (be sure to follow the links though) but in a nutshell:

Be sure to wipe out /usr/obj and /usr/src before starting.
Does not apply to you because `#make buildworld` already completed, but I'm trying to cover all grounds here.

Get the source code. I advice using a SVN mirror but in general this also works: `# svn co https://svn.freebsd.org/base/releng/11.0 /usr/src`.
Just to clarify: I'm from the Netherlands so I use the European mirror myself: `#svn co https://svn0.eu.freebsd.org/base/releng/11.0 /usr/src`.

Optional, but suggested: go into the source tree (`cd /usr/src`) and check the _new_ src.conf manual page if you plan on customizing your base system: `man -M ./share/man src.conf`.
Based on this you can add options to /etc/src.conf if applicable.
Does not apply to you because you're upgrading from the same version (and I think you're not looking to keep on using the source ).

Now check all the steps you need to perform: `less Makefile`, it will show you _exactly_ what's needed.
So just to be complete here (from /usr/src/Makefile):


```
#  1.  `cd /usr/src'       (or to the directory containing your source tree).
#  2.  `make buildworld'
#  3.  `make buildkernel KERNCONF=YOUR_KERNEL_HERE'     (default is GENERIC).
#  4.  `make installkernel KERNCONF=YOUR_KERNEL_HERE'   (default is GENERIC).
#       [steps 3. & 4. can be combined by using the "kernel" target]
#  5.  `reboot'        (in single user mode: boot -s from the loader prompt).
#  6.  `mergemaster -p'
#  7.  `make installworld'
#  8.  `mergemaster'            (you may wish to use -i, along with -U or -F).
#  9.  `make delete-old'
# 10.  `reboot'
# 11.  `make delete-old-libs' (in case no 3rd party program uses them anymore)
```
As you can see: default target is GENERIC so don't bother with specifying that if you're using it. Typing is effort afterall 

You probably done most of this already, but I figured I'd write up a complete set of instructions which you could use.

Building the kernel can take it's time. I never bothered to look at the output that much, but just as comparison: building the kernel on my (very old) P4 Toshiba laptop takes about 5 - 6 hours. The line you mentioned (CTF) can definitely be a time consuming process.

You could always use ps from another console to check if everything is still running.

Hope this can help a bit.


----------



## balanga (Feb 7, 2017)

Thanks for your complete write up, although it goes into far more depth than I will ever need (but you never know)... At least it will be a good reference for anyone trying to do such an upgrade. 

The original problem has now gone, so the lesson I've learned is not to install CURRENT versions!!! I don't think I want to go through this process again. The process I mentioned did not continue after leaving it running overnight so I had to restart the system to finish the upgrade, and am still not certain if everything was processed successfully, but at least the 'opencookie' error has disappeared.


----------

