transfig build fails without error

[jurgen.defurne@…]

After upgrading transfig, I found out that fig2dev did not work anymore. After doing some checking, I found out that the build of transfig fails, but that the build script does not detect the error exit status.

The build fails at the following point:

 genibmgl.c:575:29: error: non-void function 'set_width' should return a value [-Wreturn-type]
    if (w == current_width) return;

I have attached the debug log.

[seongmin.hwang+macport@…]

Cc Me!

[seongmin.hwang+macports@…]

Reporting a workaround (and possible solution) to this issue. I have tried the following steps:

1. Stop (Ctrl-C) the port during building process.
2. Change "return ;" to "return 0" in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_print_transfig/transfig/work/transfig.3.2.5d/fig2dev/dev/genibmgl.c (Line 575)
3. Resume the port. (sudo port install transfig)

These steps seemed to solve the problem and resulted in proper fig2dev and other associated binaries.

Regards,

Seong-min

[seongmin.hwang+macports@…]

"return 0" above should be "return 0;". Sorry for the confusion.

[jurgen.defurne@…]

As a workaround, it is good enough, thanks!

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #35628 suggests a different fix.

[Zittersteyn@…]

My system had the same issue, but killing port during building did not work. My workaround:

sudo port <enters interactive mode>

fetch transfig

<transfig is downloaded, the file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_print_transfig/transfig/work/transfig.3.2.5d/fig2dev/dev/genibmgl.c now exists, edit as Seong-min suggested>

checksum transfig

extract transfig

patch transfig

configure transfig

build transfig

destroot transfig

install transfig

activate transfig

I have no idea if the entire chain of commands is needed, documentation of the commands is rather... sparse, but this worked for me.

Thanks for the fix, this was driving me INSANE :-).

Cheers, Dirk

[Zittersteyn@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #35720.

[ryandesign (Ryan Carsten Schmidt)]

The problem occurs because of a combination of factors. First, transfig does not build with clang. The portfile was already modified in r89950 to use llvm-gcc-4.2 instead of clang, but additionally, not all parts of the transfig build were UsingTheRightCompiler, so they still used the system default compiler. With Xcode 4.4 (or even 4.3 already?) the system default compiler changed from llvm-gcc-4.2 to clang. Finally, the transfig build does not detect when parts fail to build, and it proceeds anyway, ending up with a "successful" install that's missing parts that should be there.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

The problem occurs because of a combination of factors. First, transfig does not build with clang. The portfile was already modified in r89950 to use llvm-gcc-4.2 instead of clang, but additionally, not all parts of the transfig build were UsingTheRightCompiler, so they still used the system default compiler. With Xcode 4.4 (or even 4.3 already?) the system default compiler changed from llvm-gcc-4.2 to clang.

Fixed in r96726. Now it's always UsingTheRightCompiler and -arch flags, and I added a universal variant and increased the revision to force a rebuild.

Finally, the transfig build does not detect when parts fail to build, and it proceeds anyway, ending up with a "successful" install that's missing parts that should be there.

Added detection for this problem to the portfile in r96725 so that if in the future new compilers cause other build problems, we'll be notified by the port failing to build.

[gnn@…]

Thanks! This worked for me.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #35839.