Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

In order to build netpbm, the following lines need to be added to src_unpack of
the ebuild (only ppc-macos):

  echo "DEFAULT_TARGET  = nonmerge"           >> Makefile.config
  echo "NETPBMLIBTYPE   = dylib"              >> Makefile.config
  echo "NETPBMLIBSUFFIX = dylib"              >> Makefile.config
  echo "STATICLIB_TOO   = n"                  >> Makefile.config
  echo "NETPBMLIB_RUNTIME_PATH ="             >> Makefile.config
  echo "CC              = cc -no-cpp-precomp" >> Makefile.config
  echo "CFLAGS_SHLIB    = -fno-common"        >> Makefile.config
  echo "LDSHLIB         = -dynamiclib -install_name
$(NETPBM_RUNTIME_PATH)/libnetpbm.$(MAJ).dylib" >> Makefile.config
  echo "TIFFLIB         = libtiff.dylib"      >> Makefile.config
  echo "JPEGLIB         = libjpeg.dylib"      >> Makefile.config
  echo "PNGLIB          = libpng.dylib"       >> Makefile.config
  echo "ZLIB            = libz.dylib"         >> Makefile.config
  echo "NETPBM_DOCURL   = http://netpbm.sourceforge.net/doc/" >>
Makefile.config

Actually, not all of them are really necessary.  The linking issue at
src_install should be addressed as well.  transfig and xfig will build and
install without any problem.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Tested on Mac OS X 10.3.6

Please make a makefile.config patch instead. There is no reason to clutter the
ebuild with all those extra ppc-macos-only lines.

Patch for Makefile.config below.  The symlink issue is not addressed.


--- Makefile.config     Sun Nov  2 17:48:58 2003
+++ Makefile.config     Mon Dec 13 15:01:28 2004
@@ -1,3 +1,7 @@
+####This file was automatically created by 'configure.'
+####Many variables are set twice -- a generic setting, then 
+####a system-specific override at the bottom of the file.
+####
 # This is a make file inclusion, to be included in all the Netpbm make
 # files.
 
@@ -526,3 +530,22 @@
 NETPBM_DOCURL = http://netpbm.sourceforge.net/doc/
 #For a system with no web access, but a local copy of the doc:
 #NETPBM_DOCURL = file:/usr/doc/netpbm/
+
+
+
+
+####Lines above were copied from Makefile.config.in by 'configure'.
+####Lines below were added by 'configure' based on the DARWIN platform.
+DEFAULT_TARGET = nonmerge
+NETPBMLIBTYPE=dylib
+NETPBMLIBSUFFIX=dylib
+STATICLIB_TOO=n
+NETPBMLIB_RUNTIME_PATH=
+CC = cc -no-cpp-precomp
+CFLAGS_SHLIB = -fno-common
+LDSHLIB = -dynamiclib -install_name $(NETPBM_RUNTIME_PATH)/libnetpbm.$(MAJ).dylib
+TIFFLIB = libtiff.dylib
+JPEGLIB = libjpeg.dylib
+PNGLIB = libpng.dylib
+ZLIB = libz.dylib
+NETPBM_DOCURL = http://netpbm.sourceforge.net/doc/

Created an attachment (id=53981) [details]
Altered ebuild

Created an attachment (id=53982) [details]
Patch to the ebuild

Created an attachment (id=53983) [details]
Patch applied by the new ebuild

I second that these packages work under ppc-macos. As the original reporter
said, transfig and xfig work without modifications, but for netpbm I've just
added some alternative patches taking care of the linking issue and handling
the imported libraries (TIFFLIB, JPEGLIB, etc.) on a per USE-flag-basis as the
original ebuild did it.

This is somehow ugly, perhaps some more experienced and less occupied person
than me should eventually invent a method for ebuilds to take care of the
different suffixes for different systems, which solves this more elegantally.

In order to get transfig compiling on OS X Tiger GCC 4.0 I had to apply some
patches.  A description of my findings can be read in this bug on transfig on
GCC 4.0: http://bugs.gentoo.org/show_bug.cgi?id=80760

transfig doesn't build on Panther, because panther seems not to be equipped
with
xmkmf, which Tiger apparently is.  I could not find an ebuild with provides
xmkmf... :/

xmkmf is provided by X11, so my previous comment was nonsense.

this bug actually is only about netpbm.  transfig and xfig should have their
own
separate bugs.  Transfig is already covered by bug #80760, xfig appears not yet
to be in bugzilla

When installed I get this indicating all linking is not completely ok:

% anytopnm Fantasy\ Art/stawicki-dragon\'s\ lair.jpg  
dyld: Library not loaded: /libnetpbm.10.dynlib
  Referenced from: /usr/bin/jpegtopnm
  Reason: image not found
/usr/bin/anytopnm: line 555:  5860 Trace/BPT trap          jpegtopnm "$file"

Created an attachment (id=65844) [details]
changed patch that allows anytopnm to run correctly

this patch differs from the previous that (apart from some fuzzyness fixing) it
does not specify the install name for the libnetpbm library (was called dynlib
also by the way!!!!) and as such allows anytopnm (jpegtopng actually) to run on
my Mac.

Created an attachment (id=65845) [details]
A slightly different ebuild patch for netpbm-10.28

I felt it was cleaner to avoid the many if/then/elses and just do a sed
's/\.so/.dylib/g' afterwards.  It doesn't change anything it shouldn't, so it
lookes nicer to me.  Also used userland_Darwin because this is all darwin
linker stuff.

Can someone test if this ebuild + patch work like expected?  I did some simple
test with anytopnm on a file to see if it would convert.

Created an attachment (id=65869) [details]
improved netpbm-10.28 darwin patch

Implemented suggestion/complaint by kito that the linker should be called with
-install_name, which I commented out in my previous patch.  This initially went
wrong because it used the variable $(NETPBM_RUNTIME_PATH) which was unset
lateron in the file.  Enabling this variable lead to the compilation script
thinking it was clever and pulling -rpath on the (Apple) linker, which on its
turn complained it didn't know what the hack that was supposed to mean.

So, to fix a dirty config file, the dirty way, I just copied the value of
$(NETPBM_RUNTIME_PATH) and substituted/hardcoded it in LDSHLIB.  Rationale: the
path was set the hard way in the script anyway, and by leaving the
$(NETPBM_RUNTIME_PATH) variable unset, the rest of the compilation went find. 
Now the binaries also seem to be happy with this, so I think it nears
'perfection'... ahem.

I'd still love someone to test this once before thinking of contacting the
maintainer and/or committing to CVS.

Latest patches worked like a charm with all USE flags enabled (except svga,
which is masked anyhow).

Make sure you submit this upstream please. :-)

I doubt that.  Looking through their perl configure script (yes another
package)
it seems they are aware of Darwin/OSX.  The ebuild does not  use this configure
script because it is an interactive perl script that requires input from the
user on questions, hence impossible to script.  What we basically do is hack
out
way to generate the same file as the configure script would do, using our
ebuild. :(

Created an attachment (id=65946) [details]
improved changes made to the netpbm-10.28 ebuild

It took some time and efforts after a comment by lu_zero that the symlinking of
the library in the previous ebuild was a conditional for userland_Darwin.  It
appeared that kito already made the right tools for this in multilib, hence I
rewrote the ebuild to use the multilib functions $(get_libdir) and
$(get_libname).  Initially this caused pulling some nose hair, as it seems that
$(get_libname) does not work if eutils is inherited (which should inherit
multilib on its turn).	It seems eutils is pulled as a dependency because its
functionality is available even though it is not inherited explicitly.	This IS
needed however to get multilib doing what it is supposed to do.

Result is a much cleaner ebuild, IMHO.

while trying to emerge netpbm-10.29-r1 I run into the following problem

>>> Unpacking source...
>>> Unpacking netpbm-10.29.tgz to /var/tmp/portage/netpbm-10.29-r1/work
>>> Unpacking netpbm-10.29-manpages.tar.bz2 to /var/tmp/portage/netpbm-10.29-r1/work
 * Applying netpbm-10.29-anytopnm.patch ...                               [ ok ]
 * Applying netpbm-10.29-pnmtopng-alpha-check.patch ...                   [ ok ]
 * Applying netpbm-10.29-build.patch ...                                  [ ok ]
>>> Source unpacked.
make -C lib/ -f /private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29//lib/Makefile \
    SRCDIR=/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29 BUILDDIR=/private/var/
tmp/portage/netpbm-10.29-r1/work/netpbm-10.29 all 
make -C /private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/ pm_config.h
make -C /private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/buildtools/ -f /private/
var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/buildtools/Makefile \
    SRCDIR=/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29 BUILDDIR=/private/var/
tmp/portage/netpbm-10.29-r1/work/netpbm-10.29 typegen 
c -o typegen.o typegen.c
make[3]: c: Command not found
make[3]: [typegen.o] Error 127 (ignored)
gcc -o typegen typegen.o
powerpc-apple-darwin8-gcc-4.0.0: typegen.o: No such file or directory
powerpc-apple-darwin8-gcc-4.0.0: no input files
make[3]: *** [typegen] Error 1

> while trying to emerge netpbm-10.29-r1 I run into the following problem

The problem root seems to be that the 10.29-r1.ebuild uses some elements which may lead to 
problems with my build system, namely the following variables

        CC = $(tc-getCC)
        CC_FOR_BUILD = $(tc-getBUILD_CC)
        AR = $(tc-getAR)
        RANLIB = $(tc-getRANLIB)

If I replace these by the "classic values", as in 

        CC = gcc
        CC_FOR_BUILD = gcc
        AR = ar
        RANLIB = ranlib

the package compiles, but it leaves an issue with -shared

gcc -c -I/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/lib -I. -DNDEBUG -O2 -
pipe -fPIC \
    -o libsystem.o libsystem.c
gcc -shared -Wl,-soname,libnetpbm.so.10 -o libnetpbm.so.10.29 libpm.o fileio.o bitio.o colorname.o 
libpbm1.o libpbm2.o libpbm3.o libpbmfont.o libpgm1.o libpgm2.o libppm1.o libppm2.o libppmcmap.o 
libppmcolor.o libppmd.o ppmdfont.o standardppmdfont.o libppmfloyd.o libpnm1.o libpnm2.o 
libpnm3.o libpam.o libpamread.o libpamwrite.o libpamn.o libpammap.o libpamcolor.o libsystem.o util/
shhopt.o util/nstring.o \
           
rm -f libnetpbm.a
powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared'
ar rc libnetpbm.a libpm.o fileio.o bitio.o colorname.o libpbm1.o libpbm2.o libpbm3.o libpbmfont.o 
libpgm1.o libpgm2.o libppm1.o libppm2.o libppmcmap.o libppmcolor.o libppmd.o ppmdfont.o 
standardppmdfont.o libppmfloyd.o libpnm1.o libpnm2.o libpnm3.o libpam.o libpamread.o 
libpamwrite.o libpamn.o libpammap.o libpamcolor.o libsystem.o util/shhopt.o util/nstring.o
/usr/bin/ld: unknown flag: -soname

that would imply the toolchain-funcs eclass doesn't handle ppc-macos correctly?

Dirk, what is the current value of CHOST in /etc/make.conf for you?

> Dirk, what is the current value of CHOST in /etc/make.conf for you?

CHOST="powerpc-apple-darwin"

if on Tiger you should change that into
CHOST="powerpc-apple-darwin8"

but it seems to me one of the functions from the eclass doesn't return what it
should.  The ebuild is not darwinised too, since it uses hardcoded .so, so that
won't ever work too.  Then the shared issue is just another thing to fix.

> if on Tiger you should change that into
> CHOST="powerpc-apple-darwin8"
Done

> but it seems to me one of the functions from the eclass doesn't return what it
> should.  The ebuild is not darwinised too, since it uses hardcoded .so, so that
> won't ever work too.  Then the shared issue is just another thing to fix.

Should I upgrade to a new portage? I run on 2.0.52-r1, current is portage-2.0.53_rc3 (but as usual it 
doesn't emerge cleanly because of already existing files)

you should reemerge system:
emerge -eva system

portage 2.0.53 is still in ~ppc-macos

back to this bug.  I'm going to look into this later.  I patched it before, as
in this bug in the attached patch, but I want the patch to become unconditional,
so I have te see if I can do it from the ebuild a bit more cleanly.  (Also
conditional, but just not as patch...)

sync up and try latest 10.29-r1

unfortunately need media-libs/jasper first.

got jasper, no luck:

make -C /private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/buildtools/
-f /private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/buildtools/Makefile \
    SRCDIR=/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29
BUILDDIR=/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29 typegen 
c -o typegen.o typegen.c
make[3]: c: Command not found
make[3]: [typegen.o] Error 127 (ignored)
gcc -o typegen typegen.o
powerpc-apple-darwin8-gcc-4.0.0: typegen.o: No such file or directory
powerpc-apple-darwin8-gcc-4.0.0: no input files
make[3]: *** [typegen] Error 1
make[2]: ***
[/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/buildtools/typegen]
Error 2
make[1]: ***
[/private/var/tmp/portage/netpbm-10.29-r1/work/netpbm-10.29/pm_config.h] Error 2
make: *** [lib/all] Error 2

| # Gentoo toolchain options
| CC = gcc
| CC_FOR_BUILD =
| AR = ar
| RANLIB = ranlib
| STRIPFLAG =
| CFLAGS_SHLIB = -fPIC
| 
| NETPBMLIBTYPE = dylib
| NETPBMLIBSUFFIX = dylib
| LDSHLIB = -dynamiclib -install_name $(SONAME)

on linux this looks like:
| CC = i686-pc-linux-gnu-gcc
| CC_FOR_BUILD = i686-pc-linux-gnu-gcc
| AR = i686-pc-linux-gnu-ar
| RANLIB = i686-pc-linux-gnu-ranlib
| STRIPFLAG =
| CFLAGS_SHLIB = -fPIC

so it's figuring out why the eclass doesn't work well on OSX/Darwin

hrm, i thought i fixed that

see if updating toolchain-funcs.eclass tc-getBUILD_CC() works ... add this line
before the last 'export BUILD_CC':

search=${search:-gcc}

that seems to do the trick at least to get into compilation stage for me.

I now have:
| # Gentoo toolchain options
| CC = gcc
| CC_FOR_BUILD = gcc
| AR = ar
| RANLIB = ranlib
| STRIPFLAG =
| CFLAGS_SHLIB = -fPIC

and need to deal with the following linking error:
rm -f libnetpbm.a
ar rc libnetpbm.a libpm.o fileio.o bitio.o colorname.o libpbm1.o libpbm2.o
libpbm3.o libpbmfont.o libpgm1.o libpgm2.o libppm1.o libppm2.o libppmcmap.o
libppmcolor.o libppmd.o ppmdfont.o standardppmdfont.o libppmfloyd.o libpnm1.o
libpnm2.o libpnm3.o libpam.o libpamread.o libpamwrite.o libpamn.o libpammap.o
libpamcolor.o libsystem.o util/shhopt.o util/nstring.o
ranlib libnetpbm.a
ld: common symbols not allowed with MH_DYLIB output format with the
-multi_module option
libpm.o definition of common _pm_plain_output (size 4)
/usr/bin/libtool: internal link edit command failed
make[1]: *** [libnetpbm.10.29.dylib] Error 1
make: *** [lib/all] Error 2

(In reply to comment #31)

> rm -f libnetpbm.a
> ar rc libnetpbm.a libpm.o fileio.o bitio.o colorname.o libpbm1.o libpbm2.o
> libpbm3.o libpbmfont.o libpgm1.o libpgm2.o libppm1.o libppm2.o libppmcmap.o
> libppmcolor.o libppmd.o ppmdfont.o standardppmdfont.o libppmfloyd.o libpnm1.o
> libpnm2.o libpnm3.o libpam.o libpamread.o libpamwrite.o libpamn.o libpammap.o
> libpamcolor.o libsystem.o util/shhopt.o util/nstring.o
> ranlib libnetpbm.a
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
> libpm.o definition of common _pm_plain_output (size 4)
> /usr/bin/libtool: internal link edit command failed
> make[1]: *** [libnetpbm.10.29.dylib] Error 1
> make: *** [lib/all] Error 2
> 

Not sure why it would be an MH_DYLIB when its trying to create a static archive... can try adding -fno-
common to CFLAGS or changing -multi_module to -single_module, but something else doesn't sound 
right...

ok, fixed the BUILD_CC func in toolchain-funcs.eclass

ok, I gave this one a fling again.

% anytopnm 83.jpg
dyld: Library not loaded: libnetpbm.dylib.10
  Referenced from: /usr/bin/jpegtopnm
  Reason: image not found

this is obvious, as it should point to libnetpbm.10.dylib instead (which indeed
exists).

It's not so obvious to me as how to get that corrected.

netpbm is in the tree and keyworded ~ppc-macos, ~x86-macos.

this bug can be closed.

please use prefix.