Solved Trouble with compiling openjpeg15 from ports

gladiola

gladiola

I sent an email to the port maintainer. I read over the Makefile. It mostly set variables. I didn't see how it associated with the error I was receiving. Last Makefile revision calls back to a website with a tld for Poland. The port maintainer is mailing from here.

No graphics/openjpeg15 causes compile failures for net/wireshark. Since its only the most popular program for packet capture on the face of the earth, I guess we shouldn't be too surprised that this one didn't make either. Last revision, December. Surely, this hasn't been broken since then.

FreeBSD 10.2 amd64. Reinstalled graphics/cmake, graphics/lcms2, graphics/png and graphics/tiff. These actions had no effect on the error.

Copy of the errors is attached in msg.txt. The error messages suggest a missing header file in the source code. Missing includes; compile failure.
 

Attachments

It just built for me with no errors. opj_config.h appears to be in /usr/ports/graphics/openjpeg15/work/openjpeg-version.1.5.2 while it is being built.
 
This is just another example among countless of why building on a live system using "make" is a terrible idea.
Use poudriere or synth and this self-inflicted problem goes away.

FYI, if openjpeg15 really didn't build, there would be a riot. It would probably take out 15,000 ports with it. So that should tell you that it's "just you".
 
Email to the person who wrote the makefile was undeliverable.

If all you have to say is, Do it some other way, that's not helpful. I have been compiling programs from publicly available sources since the 1980s. I'm not interested in changing the media of program arrival. If the code is published, I expect it to work.

It may be "not you," because you're not building my type of system from scratch. If all you have to say is "your fault," that's not helpful. If you can't answer the question, then don't post. This one is about getting the code to compile.

I will check that cmake.conf later, Dice. I did a reinstall, so, I am not sure what to expect in there that might interfere.

I had awesome performance under all of the i386 installs I've done over the years. I switched to Lenovo T420 based on the laptop hardware chart. I also then switched to amd64 image. This installation has sucked at every step. 50% of everything I normally use looks broken.

Chromium compiled faster on this one. No other plusses.

I have other FreeBSD 9 & 10 installs on 6+ different machines scattered around my desk, from Dell Hackintosh Mini 10s to a 1998 box I found on the side of the road; this one has been poor to the point of profane. To get FreeBSD on that netbook, I had to rip out the hard drive and load it by cloning the image from another computer. But, in that case, the codebase was good.

Over and over again, I have compiled from ports successfully. I think it is a great idea. Where else, except from ports, do you stand a chance to see what's going on when you get your system a new program?

In my view, this is what computing is about. I don't want someone's binaries. I don't want a copy with bogus licensing or fees. I want to read the code or at least see the code working. I compile from ports.

This time, I cannot turn around without a stuck jam-up in ports. Normally just going over there and reinstalling works. Frequently, just go to the dependent program port and troubleshoot from there. Maybe, at most, I might have to wait until the weekend to get better code. I'm not seeing that with this. So far, this is "just sucks" all around.

I had no idea things would be this bad by making these changes in the starting point. Of course, we know it's influential. It has been hang up after hang up.

I will write back later. I don't expect to ever apologize for having trouble with a system. If it's been publicly deployed, then it's expected to be robust.
 
gladiola said:
If all you have to say is, Do it some other way, that's not helpful. I have been compiling programs from publicly available sources since the 1980s. I'm not interested in changing the media of program arrival. If the code is published, I expect it to work.
Click to expand...

Then your expectatation are unrealistic. It's been said time and time again that this method is unsafe. This is what you should expect.
In other words, the way you've been doing it since the 1980's is wrong.

It may be "not you," because you're not building my type of system from scratch. If all you have to say is "your fault," that's not helpful. If you can't answer the question, then don't post. This one is about getting the code to compile.
Click to expand...

The proof is in the pudding. It builds for everyone that has an up-to-date system. Your method fails to get the system in a good state and it fails to build. It's that simple.

Over and over again, I have compiled from ports successfully. I think it is a great idea. Where else, except from ports, do you stand a chance to see what's going on when you get your system a new program?
Click to expand...

poudriere and synth are about compiling from source, so I'm not sure what point you are trying to make.

In my view, this is what computing is about. I don't want someone's binaries. I don't want a copy with bogus licensing or fees. I want to read the code or at least see the code working. I compile from ports.
Click to expand...

We're talking about the same thing.

This time, I cannot turn around without a stuck jam-up in ports. Normally just going over there and reinstalling works. Frequently, just go to the dependent program port and troubleshoot from there. Maybe, at most, I might have to wait until the weekend to get better code. I'm not seeing that with this. So far, this is "just sucks" all around.
Click to expand...

it's self-inflicted pain due to following a process you think is correct but isn't.

If it's been publicly deployed, then it's expected to be robust.
Click to expand...
Invalid, b/c the problem is with your process.
 
Stud programmer and port maintainer has written back. He replied that the object is set in the make config. Will advise later. 73
 
Port maintainer advised to try a make clean configure and check for the files. I noticed that the required header is landing one directory above where I would expect it to be, by its reference in the code for openjpeg.c.

In order to find the files that are troublesome, I had to burrow down into the "work" subdirectory that gets created during the preparation and compilation process. Also, had to check "files", later. That's where openjpeg.c and its header turn up.

Initially, I tried moving the header or editing the include; what will happen is that an adjacent PROG.c will fail. It looked like the Java-related ones would go next. Rather than continuing to manually edit each program, I decided to stop that and observe some more.

I undid that change with another make clean configure, backed up and looked around some more. I tried the configure and installation process a couple more times; of course, there was no significant difference. With the headers landing in the wrong directory, the only answer will be to fix that.

Looking over the files that guide the makes, I found a note that specified that library paths were hard coded into the programs and that the architecture choices between i386 and 64 bit would be different. That was in /usr/ports/graphics/openjpeg15/files/patch-CMakeLists.txt.

During the troubleshooting process, I directed some standard out to text file. Some of that is attached.
msgA.txt is the std out from after a make clean configure.
msgB.txt is the std out from after a make install clean.
sampleAroundError.txt is a collection of samples from related files; includes the source code with the call to the header, directories around that .c file, directories where that .h file is ending up on its own.

It looks to me like the make is not putting the header where it is needed. Another email to the port maintainer, and we'll see what the reply is.
 

Attachments

Yesterday I updated about 30 servers, most of them 9.3-RELEASE (3 i386, the rest AMD64) and a few 10.1-RELEASE versions. The graphics/openjpeg15 is a dependency of some of the stuff we have running. I had zero problems building and installing it on all 30 servers. So I'm struggling to figure out why it's not working for you.

Maybe you already posted it and I missed it but what's in /etc/make.conf?
 
Program documentation at http://www.freebsd.org/ports/graphics.html suggests that there are more requirements that I could not locate with whereis
Code: 
Requires: ca_root_nss-3.22.2, cmake-3.5.0, cmake-modules-3.5.0,
curl-7.47.1, expat-2.1.0_3, jbigkit-2.1_1, jpeg-turbo-1.4.2,
jsoncpp-0.6.0.r2_2, lcms2-2.7_2, libarchive-3.1.2_6,1, lzo2-2.09,
pkgconf-0.9.12_1, png-1.6.21, tiff-4.0.6_1
The program seemed to explicitly check for four of these: the TIFF, PNG, LCMS2 and the CMAKE. I know I have a CURL. Looking over the rest of the list, I will track those down and see if the next compilation goes any better.
 
Made it.

When I went through the list of the requirements, I was able to find most of each. They weren't turning up on my whereis because I did not use the full program titles. I just got to the ports. I did several make reinstall. Several of them were down by a minor version or two, but I was not surprised at that.

I did come across an unusual error when I got to checking on jpeg-turbo.
Code: 
===>   Registering installation for jpeg-turbo-1.4.2
Installing jpeg-turbo-1.4.2...
pkg-static: jpeg-turbo-1.4.2 conflicts with jpeg-8_6 (installs files
into the same place).  Problematic file: /usr/local/bin/cjpeg
*** Error code 70
I deinstalled that jpeg-8_6 and installed the jpeg-turbo.
openjpeg15 compiled right away.

I'm not sure why I had that jpeg-8_6; my only other graphics-related program that catches my interest, XPDF, also calls for jpeg-turbo. I guess I am going to keep it.

Wireshark seems to have been compiling for longer than before, so maybe that one will make, too.
CeW3B12XEAAGBkh.jpg:large

Wireshark on X11 Xorg with twm from ports.
 
gladiola said:
I did come across an unusual error when I got to checking on jpeg-turbo.
Code: 
===>   Registering installation for jpeg-turbo-1.4.2
Installing jpeg-turbo-1.4.2...
pkg-static: jpeg-turbo-1.4.2 conflicts with jpeg-8_6 (installs files
into the same place).  Problematic file: /usr/local/bin/cjpeg
*** Error code 70
I deinstalled that jpeg-8_6 and installed the jpeg-turbo.
openjpeg15 compiled right away.

I'm not sure why I had that jpeg-8_6; my only other graphics-related program that catches my interest, XPDF, also calls for jpeg-turbo. I guess I am going to keep it.
Click to expand...
You probably forgot to read /usr/ports/UPDATING:
Code: 
20150916:
  AFFECTS: users of graphics/jpeg
  AUTHOR: antoine@FreeBSD.org

  Default implementation of jpeg has been switched from graphics/jpeg to
  graphics/jpeg-turbo.  To perform the upgrade, use instructions below.

  If using binary packages: 'pkg upgrade' will do the right thing.  If it
  doesn't and complains about 'Cannot solve problem using SAT solver', run
  'pkg delete -f jpeg' before 'pkg upgrade'.

  If using portmaster:
  # portmaster -o graphics/jpeg-turbo jpeg

  If using portupgrade:
  # portupgrade -f -o graphics/jpeg-turbo graphics/jpeg

  If you compile your ports and want to keep using IJG's jpeg implementation,
  add this line to your /etc/make.conf file:
  JPEG_PORT=graphics/jpeg

Always read /usr/ports/UPDATING before updating anything. Sometimes you have to do things in a specific order or things will break.
 
Not only did I forget to read it, I was surprised in the first place that a packet analyzer would be calling a jpeg program. Further, I couldn't tell you off the top of my head which programs before it used the jpeg 8_6. It's not as though I woke up and said, "Can't wait to get more graphics standards in here." Further, I suppose I will still have to live with the evaluative judgement; like, because I chose jpeg-turbo, what will that do for the other programs that must have been the cause of pulling jpeg 8_6? Many of these programs I load from ports are basically accepted by default. A program will compile, tell me its missing a dependency, and a make config dialog will pop up. Of course, I will be foolhardy and accept whatever the system suggests. Thanks.
 
You must log in or register to reply here.
Back
Top