djview @4.10 fails to build on PPC 10.5

[reeskm (Rees Machtemes)]

I can't get djview 4.10 to build. I have 4.9 installed and working great.

It fails when linking djview.app/Contents/MacOS/djview with a no such file and "invalid arch name : -o"

Attached is the log output with -v

[reeskm (Rees Machtemes)]

djview @4.10 build log

[ryandesign (Ryan Carsten Schmidt)]

Unfortunately the log doesn't actually show us what commands were being run, because djview was building with silent rules. I've disabled them in r137262. If you sudo port selfupdate and try again, the log that's generated should have more detail.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[reeskm (Rees Machtemes)]

after disabling silent rules

[reeskm (Rees Machtemes)]

Replying to ryandesign@…:

Unfortunately the log doesn't actually show us what commands were being run, because djview was building with silent rules. I've disabled them in r137262. If you sudo port selfupdate and try again, the log that's generated should have more detail.

ryandesign, I have followed your directions and attached the result.

[ryandesign (Ryan Carsten Schmidt)]

Thanks, that shows me what I expected to see, which is that the Makefile is invoking the compiler with the flags "-arch ppc -arch -o djview.app/Contents/MacOS/djview" which is not correct. The second "-arch" shouldn't be there. Alternately, the second "-arch" should be followed by "ppc" as the first one is. The question is: why are these flags being used?

I believe this is a bug in qmake (which is a part of Qt). There are two problems which together are causing this.

The first problem is that for some reason, every compiler invocation in your log has the -arch ppc flags repeated a second time. I don't know where this comes from, and I don't see it on my Yosemite system, but there are of course many differences between an Intel Yosemite system and a PowerPC Leopard system. Normally, it would be no problem to repeat the -arch XXX flags; the compiler will just ignore the duplicate architectures.

The second problem is that it seems that qmake tries to be clever and removes what it considers to be duplicate flags. At least I think that's the explanation. It evidently has some intelligence to know that -arch flags are special and should not be deduplicated, but somehow if the same -arch XXX flags are specified more than once, then only the first occurrence of the architecture name is preserved and the subsequent ones are removed, leaving invalid -arch flags. A version of this problem was reported in ​Qt bug 24662. It was closed without being fixed and indeed without the developers seeming to understand the problem in the slightest. (The developer's suggestion regarding -Xarch_i386 is completely off-topic.)

I was able to reproduce the problem on my Yosemite system by forcing MacPorts to use the same -arch flags twice: I edited macports.conf and changed universal_archs to x86_64 x86_64, then built djview with the +universal variant. Obviously this is a silly setting that nobody would really use, but it caused MacPorts to pass -arch x86_64 -arch x86_64 to the build system, which caused it to fail the same way for me that it did for you. Of note: qt4-mac also fails to configure +universal with this setting, reinforcing the idea that this is a Qt bug.

It seems that qmake is aware to some degree that it will create these invalid combinations of flags, because after qmake runs and before it writes it to the Makefile.qmake file, it sends the output through this transform:

/opt/local/bin/gsed 's/-arch *-/-/g'

That is: if there are any occurrences of -arch followed by a space and a dash, then delete the occurrence of -arch. This would have fixed the problem if the literal string "-arch -o" had appeared in the file, but it doesn't: "-arch ppc -arch" appears at the end of a line (the line setting the LFLAGS variable), and then later it invokes:

$(vLINK)$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)

which is where the -o gets placed right after an -arch.

The real solution is for qmake to not deduplicate -arch XXX flags.

[ryandesign (Ryan Carsten Schmidt)]

I'm able to work around the problem by adding no_lflags_merge to the end of the CONFIG += line in src/djview.pro, and installing automake 1.14.1. But it doesn't seem like each project should have to do something like that.

[reeskm (Rees Machtemes)]

I wonder if this is a problem with my macports.conf. I have kept my macports install for years - at least since 2010. I have attached it.

[reeskm (Rees Machtemes)]

My macports.conf

[michaelld (Michael Dickens)]

Can you post the file " $(port work djview)/djview*/src/Makefile.qmake"?

[reeskm (Rees Machtemes)]

Makefile.qmake

[reeskm (Rees Machtemes)]

Replying to michaelld@…:

Can you post the file " $(port work djview)/djview*/src/Makefile.qmake"?

Attached!

Not only is "-arch ppc" duplicated in the CFLAGS and CXXFLAGS lines (35, 36), but you also have "-arch ppc -arch" in LFLAGS (line 39).

Weird! Do I have some local options set for optimization that might be my fault, or is this Michael what you have been referring to in Comment:5 as a possible qmake bug?

Can I edit the portfile to use another version of Qt? Is my Qt built improperly or needs a rebuild?

[michaelld (Michael Dickens)]

It's the one in LFLAGS that's causing the issue. This is a bug in qmake, which I thought was squashed back in Qt 4.6 or 4.7 somewhere.

For better or worse, the Makefile.qmake is not generated until during the build phase. It's probably possible to coerce the configuration phase to create it (and then we could patch it post-configure), but that would take some work.

I see nothing obviously wrong in the macports.conf file. That said, you might want to start from scratch with a fresh install & just tweak the few settings you need for your specific setup.

What does "port installed and active" return for you?

Are you using the most recent ports -- looks like not, by the location of Qt4 (prefix == /opt/local, not /opt/local/libexec/qt4). I don't know that this makes a lot of difference, but it might.

[reeskm (Rees Machtemes)]

Replying to michaelld@…:

I see nothing obviously wrong in the macports.conf file. That said, you might want to start from scratch with a fresh install & just tweak the few settings you need for your specific setup.

Good to know! But as for restart from scratch - it would take days! This will be my last resort.

What does "port installed and active" return for you?

Attached.

Are you using the most recent ports -- looks like not, by the location of Qt4 (prefix == /opt/local, not /opt/local/libexec/qt4). I don't know that this makes a lot of difference, but it might.

Pretty sure I am. I'm using qt4-mac@4.8.7_3. I tried upgrading it, but it seems this is the latest version. Not sure about that prefix line you mention and why it is not what you expect. Maybe because I installed MacPorts a long time ago it uses older prefixes?

[reeskm (Rees Machtemes)]

port installed and active (output)

[reeskm (Rees Machtemes)]

I should mention that since reporting this bug, I am now running macports 2.3.4. Should we update the header above?

[michaelld (Michael Dickens)]

I recently changes the Qt4 portgroup to install into the latter prefix, from the former. It should be active in 4.8.7_3. If you look at "port contents qt4-mac", which prefix does it use? Also, what is the result of "port provides /opt/local/Library/Frameworks/QtCore.framework/QtCore"? I'm thinking you might have multiple Qt installs in place (cruft), and the old one is one that still has this -arch bug in its qmake.

[reeskm (Rees Machtemes)]

Replying to michaelld@…:

I recently changes the Qt4 portgroup to install into the latter prefix, from the former. It should be active in 4.8.7_3. If you look at "port contents qt4-mac", which prefix does it use? Also, what is the result of "port provides /opt/local/Library/Frameworks/QtCore.framework/QtCore"? I'm thinking you might have multiple Qt installs in place (cruft), and the old one is one that still has this -arch bug in its qmake.

I think it's using the right prefix. Also, your port provides command might have an issue? Or are you sure that is what you have intended. Files attached above.

[michaelld (Michael Dickens)]

What does

ls /opt/local/Library/Frameworks/Qt*

return for you, if anything beyond "No such file or directory"? For me, it returns:

ls: /opt/local/Library/Frameworks/Qt*: No such file or directory

[reeskm (Rees Machtemes)]

Replying to michaelld@…:

What does

ls /opt/local/Library/Frameworks/Qt*

return for you, if anything beyond "No such file or directory"? For me, it returns:

ls: /opt/local/Library/Frameworks/Qt*: No such file or directory

Same result here.

I just built qt4-creator-mac for fun. I assume it uses qmake. It built successfully. I tried looking up the logfile but unfortunately I just remembered my macports.conf is set to delete logs for successful builds.

[michaelld (Michael Dickens)]

The reason I ask is that in your log file, I see the following:

/opt/local/bin/qmake -spec /opt/local/share/qt4/mkspecs/macx-g++ CONFIG+=autoconf CONFIG+=release\
		QMAKE_UIC=/opt/local/bin/uic \
		QMAKE_MOC=/opt/local/bin/moc \
		QMAKE_RCC=/opt/local/bin/rcc \
		QMAKE_LFLAGS+='-arch ppc -L/opt/local/lib' \
		QMAKE_CFLAGS+='-pipe -arch ppc -I/opt/local/include -I/opt/local/include   -I.. -I. -DDIR_DATADIR=\\\"/opt/local/share\\\"' \
		QMAKE_CXXFLAGS+='-pipe -arch ppc -I/opt/local/include -I/opt/local/include   -I.. -I. -DDIR_DATADIR=\\\"/opt/local/share\\\"' \
		QMAKE_CPPFLAGS+='-I/opt/local/include -I/opt/local/include -I/opt/local/include   -I.. -I. -DDIR_DATADIR=\\\"/opt/local/share\\\"' \
		LIBS+='-L/opt/local/lib -ldjvulibre  -ltiff ' \
		VPATH='.' -o - djview.pro |\
	  /usr/bin/awk -f ../config/qmsilent.awk |\
	  /opt/local/bin/gsed 's/-arch *-/-/g' > Makefile.qmake
Project MESSAGE: qtAddLibrary: found framework QtOpenGL in directory /opt/local/Library/Frameworks
Project MESSAGE: qtAddLibrary: found framework QtGui in directory /opt/local/Library/Frameworks
Project MESSAGE: qtAddLibrary: found framework QtNetwork in directory /opt/local/Library/Frameworks
Project MESSAGE: qtAddLibrary: found framework QtCore in directory /opt/local/Library/Frameworks
/usr/bin/make -f Makefile.make

[michaelld (Michael Dickens)]

So, the big question is whether this issue is a product of cruft / old ports being around that are no longer there. Have you tried anything like the following yet?

sudo port clean djview
sudo port selfupdate
sudo port install djview

[reeskm (Rees Machtemes)]

Replying to michaelld@…:

So, the big question is whether this issue is a product of cruft / old ports being around that are no longer there. Have you tried anything like the following yet?

sudo port clean djview
sudo port selfupdate
sudo port install djview

I tried this again, just to be sure it's starting from a clean build. Same result - fail. Attached the log just in case there is any difference that might point us to a solution.

[reeskm (Rees Machtemes)]

log after a port clean djview; port selfupdate; port install djview

[michaelld (Michael Dickens)]

OK; now I believe you're using the latest qt4-mac.

[michaelld (Michael Dickens)]

Are you comfortable with editing a Portfile (at all)? If so, I'd like for you to edit the patch file "patch-makefile-qmake-workaround.diff" as follows: Change the lines that read:

+	  $(SED) 's/-arch *-/-/g' > $@

to

+	  $(SED) -e 's/-arch *-/-/g' -e 's/-arch *$//g' > $@

Now, do:

sudo port clean djview
sudo port install djview

and see if that works. The added SED script will remove the stray -arch from LFLAGS, which will hopefully allow the port to build. It won't hurt if the stray -arch is not there.

[reeskm (Rees Machtemes)]

Build failed. This is a snippet from the log. I'm getting a sed error. I'm not a sed expert... Let me know if you need something else.

t/local/include   -I.. -I. -DDIR_DATADIR=\\\"/opt/local/share\\\"' \
		LIBS+='-L/opt/local/lib -ldjvulibre  -ltiff ' \
		VPATH='.' -o - djview.pro |\
	  /usr/bin/awk -f ../config/qmsilent.awk |\
	  /usr/bin/sed -e 's/-arch *-/-/g' -e 's/-arch */g' > Makefile.qmake
sed: 1: "s/-arch */g\n": unescaped newline inside substitute pattern

[michaelld (Michael Dickens)]

The second "-e" entry should contain *$//g, not */g. If, when you edit the patch file you find that change already in place (the actual characters are in the patch file correctly), then try *\$//g in the patch file. Unfortunately, you'll need to "clean" and redo the whole install to get this change in place :(

[reeskm (Rees Machtemes)]

It's still not working for me. Files attached.

[reeskm (Rees Machtemes)]

changed patch file - creates errors during install

[reeskm (Rees Machtemes)]

after changing patch file, fails with sed syntax error

[michaelld (Michael Dickens)]

OK; sorry about that. My Makefile-foo isn't as strong as it could be. Try switching that line to the following:

	  $(SED) -e 's/-arch *-/-/g' -e 's/-arch *$$//g' > $@

When I intentionally introduce the types of -arch issues that qmake sometimes creates into the file, this line removes them. Hopefully it'll do the same for you. Again: fix the patch file then clean before building.

[reeskm (Rees Machtemes)]

That worked! We are getting somewhere now! However, there is a new problem, unrelated to "-arch" issues, I think.

It seems despite "nsdejavu" and "npdejavu" options being disabled in the build, it fails to build the "nsdejavu" source. Why does it even try and parse that subdirectory? Why does it even create a nsdejavu makefile?

(I believe these are netscape plugins - totally un-needed IMHO).

Log attached.

[reeskm (Rees Machtemes)]

fails trying to build "nsdejavu" netscape plugin code

[michaelld (Michael Dickens)]

Looks like the configure script fails to properly not build those plugins. Ditto for my current 10.11 box. Probably can work around that.

The issue is that the macros __powerpc__ and __powerpc64__ are not being defined by the compiler. I would guess that they are instead __ppc__ and __ppc64__. Can you issue the following & report back what is says:

/usr/bin/g++-4.2 -arch ppc64 -dM -E - < /dev/null | grep -i ppc
/usr/bin/g++-4.2 -arch ppc -dM -E - < /dev/null | grep -i ppc

If the results are what I expect, then I can create a patch that might work to allow the build to at least finish.

[reeskm (Rees Machtemes)]

You are right! I assume another change to the patch is in order to add some extra #define(s)?

[rees@powermacg5 ~]$/usr/bin/g++-4.2 -arch ppc64 -dM -E - < /dev/null|grep -i ppc
#define _ARCH_PPCGR 1
#define __ppc64__ 1
#define _ARCH_PPC 1
#define _ARCH_PPC64 1
[rees@powermacg5 ~]$/usr/bin/g++-4.2 -arch ppc -dM -E - < /dev/null|grep -i ppc#define _ARCH_PPCGR 1
#define __ppc__ 1
#define _ARCH_PPC 1

[michaelld (Michael Dickens)]

I just pushed some changes in r145204 that will hopefully address all of these issues. You'll need to clean and revert the djview port directory to its original state before doing a selfupdate. Once you've done all of that, try upgrading djview & see if it works. Does this make sense?

[michaelld (Michael Dickens)]

Even with the former change, the buildbots we use were failing because the plugin was trying to be build. There's a typo in the configure script that was causing this issue, which I fixed with a patch in r145205. So, you should be good to go between the various changes no in place.

[reeskm (Rees Machtemes)]

It built and installed!

But... half of my djvu documents on my disk crash DJView on initial loading. The question is - does this happen on you with OSX 10.11?

I have attached a crash report from OSX 10.5. I tried to see if it would give me an obvious clue as to what the issue was.

Is it MacPorts related with some other dependency lib perhaps? Or is this strictly a DJView bug?

[reeskm (Rees Machtemes)]

Apple crash reporter - after initial loading of a djvu file

[reeskm (Rees Machtemes)]

I have attached a public domain DJVU file that crashes my install. It's the "Adventures of Sherlock Holmes. As soon as the title page is displayed, you get the standard Mac spinning wheel and then the app crashes.

This should help reproduce the problem!

I have some files that do not crash the app, but they are not public domain and so I don't feel comfortable posting them. You'll just have to take my word for now that they load and play fine.

[reeskm (Rees Machtemes)]

This djvu file crashes the app

[michaelld (Michael Dickens)]

I can load that file & it works nicely for me on 10.11. The crash is in djvulibre library, so not part of djview directly. Given that 10.5 isn't supported officially, and nor is PPC, I think we did pretty well even if I would love to see djview work for you! Given that we fixed this ticket's issue, I'm going to close it as fixed. Please open a new ticket with this iteration of the problem & cc me. Post the crash log & anything else relevant that you can think of. Not sure what to do, but I'll think on it.