rrdtool 1.3.3 build fails (internal link edit command failed)

[vinc17@…]

I get the following error on Mac OS X 10.4.11:

ld: symbols names listed in -exported_symbols_list: .libs/librrd-symbols.expsym not in linked objects
_#
/usr/bin/libtool: internal link edit command failed

[vinc17@…]

Update summary since I have the same problem with rrdtool 1.3.3.

[macports@…]

Just another confirmation - rrdtool 1.3.3 fails as a prereq for ntop with the error given. Using XCode 2.4.1 under 10.4.11.

[macports@…]

Cc Me!

[news@…]

Same problem here! Please fix it soon. Last good version installed: rrdtool @1.3.1_1 (active)

 system_profiler  -detailLevel mini
Hardware:

    Hardware Overview:

      Model Name: Mac Pro
      Model Identifier: MacPro1,1
      Processor Name: Dual-Core Intel Xeon
      Processor Speed: 2.66 GHz
      Number Of Processors: 2
      Total Number Of Cores: 4
      L2 Cache (per processor): 4 MB
      Memory: 4 GB
      Bus Speed: 1.33 GHz
      Boot ROM Version: MP11.005C.B08
      SMC Version: 1.7f10

Software:

    System Software Overview:

      System Version: Mac OS X 10.4.11 (8S2167)
      Kernel Version: Darwin 8.11.1

[news@…]

Cc Me!

[robert@…]

Cc Me!

[vinc17@…]

Replying to news@…:

Last good version installed: rrdtool @1.3.1_1 (active)

Except that it is not good. Really bad in fact: ​http://oss.oetiker.ch/rrdtool-trac/ticket/178

I suggest that you downgrade to 1.2.x until 1.3.3 can be compiled.

[markd@…]

The data corruption bug is fixed, and it builds fine on 10.5, so I'd rather contact the developer first since he usually fixes things fast. I didn't know it was broken on 10.4 but I duplicated the problem to send it to the list.

[chrisric@…]

Cc Me!

[chrisric@…]

Hi - Is there a fix out for this yet? Thanks.

[macports@…]

Update: Build still fails with internal link error under version 1.3.4.

Also found an identical report on the developer mailing list from Sept 18 - ​http://oss.oetiker.ch/rrdtool/forum.en.html#nabble-td1099468, where it is suggested that the recent Solaris fixes may have caused the break. Next step is if someone can provide developer with the requested 'configure' output comparison between 10.4.x and 10.5.x.

[markd@…]

That was my post. I did supply those and it didn't help Tobi determine what the problem was. The only thing I know to do is resurrect 1.2.27 as rrdtool12.

[vinc17@…]

Have you tried without the Solaris fixes?

[markd@…]

I'm not sure what the Solaris fixes were. 1.3.1 works is all I know.

[markd@…]

Getting closer. Can anyone find out why this is happening?

ttps://lists.oetiker.ch/pipermail/rrd-users/2008-October/014792.html

[markd@…]

​https://lists.oetiker.ch/pipermail/rrd-users/2008-October/014792.html

[blb@…]

Try the attached patch to rrdtool's configure script. It gets rid of the _# on 10.5 but I haven't tested on 10.4. If it works I can explain what's going on in it.

[vinc17@…]

It doesn't work: I get the following error:

(cd .libs/librrd.lax/librrdupd.a && ar x /opt/local/var/macports/build/_Users_vinc17_wd_macosx_dports_net_rrdtool/work/rrdtool-1.3.4/src/./.libs/librrdupd.a)
sed -E -e 's,^([^#]),_\1,' < librrd.sym > .libs/librrd-symbols.expsym
sed: invalid option -- E
[...]

[blb@…]

Interesting, 10.4's man page claims to support the -E option; do you have the gsed port installed with the +with_default_names variant? If that's it, I can hardcode /usr/bin for those sed calls.

[vinc17@…]

Yes, I have sed from the gsed port. Better than hardcoding /usr/bin, you could use POSIX syntax. But even when I fix the sed commands to sed -e 's,^\([^#]\),_\1,' I get the following error (under 10.4.11):

/usr/bin/gcc-4.0 -dynamiclib -O2 -D_GNU_SOURCE -fno-strict-aliasing -Wall -std=c99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wold-style-definition -W  -fno-common -DPIC -L/opt/local/lib -L/opt/local/lib -L/usr/X11R6/lib   -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices   -L/opt/local/lib -L/usr/X11R6/lib   -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices   -Wl,-single_module  -L../../src/.libs -L../../src -L/opt/local/lib tclrrd.o -o tclrrd1.3.4.dylib -lrrd_th -lm -L/opt/local/lib -ltclstub8.5 -L/opt/local/lib -L/opt/local/lib -L/usr/X11R6/lib   -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices   -L/opt/local/lib -L/usr/X11R6/lib   -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices   
ld: Undefined symbols:
_rrd_parsetime
/usr/bin/libtool: internal link edit command failed
gnumake[3]: *** [tclrrd1.3.4.dylib] Error 1

[vinc17@…]

The problem seems to come from the first three -L/opt/local/lib, which are before the source/build-related paths -L../../src/.libs and -L../../src (when I remove them, I no longer get the error).

[vinc17@…]

The bug is in the configure file that sets TCL_SHLIB_LD to '${CC} -dynamiclib ${CFLAGS} ${LDFLAGS} -Wl,-single_module'. It must not contain ${LDFLAGS} since bindings/tcl/Makefile has:

$(TCL_RRD_LIB): tclrrd.o
        $(TCL_SHLIB_LD) $(TCL_LD_SEARCH_FLAGS) $(LIBDIRS) $< -o $@ -lrrd_th -lm $(TCL_STUB_LIB_SPEC) $(LDFLAGS) $(LIBS)

where $(LIBDIRS) contains the source/build-related paths -L../../src/.libs and -L../../src (which must come first). Note that $(LDFLAGS) is already listed later.

[blb@…]

patch to configure

[blb@…]

Replying to vinc17@…:

Yes, I have sed from the gsed port. Better than hardcoding /usr/bin, you could use POSIX syntax.

That'll work, patch has been updated.

I get the following error (under 10.4.11):

Is this with an upgrade? Perhaps this is a port which doesn't like to be built when another version is already available? You can try deactivating the current one, see if it builds then.

[blb@…]

Replying to vinc17@…:

The bug is in the configure file that sets TCL_SHLIB_LD to '${CC} -dynamiclib ${CFLAGS} ${LDFLAGS} -Wl,-single_module'.

Interesting, it looks like that setting may be coming from ${prefix}/lib/tclConfig.sh, which sets

TCL_SHLIB_LD='${CC} -dynamiclib ${CFLAGS} ${LDFLAGS} -Wl,-single_module'

(among other things). So does the tcl port need to remove it (note that /usr/lib/tclConfig.sh also adds LDFLAGS to TCL_SHLIB_LD) or should rrdtool's configure strip it?

[vinc17@…]

If I understand correctly, TCL_SHLIB_LD is there to provide a linker command, not to provide library-path flags (that it doesn't use directly). As you could see, library-path flags are provided in another way, as usual.

Now, one may wonder if LDFLAGS may contain library-path flags or just flags to modify the behavior of the linker. Unfortunately the former choice has been made by MacPorts (I would have rather seen these paths provided via $LIBRARY_PATH to avoid such conflicts). So, anyway one no longer has the choice: remove LDFLAGS from TCL_SHLIB_LD.

[vinc17@…]

If I remove ${LDFLAGS} from $prefix/lib/tclConfig.sh, then the port can be built, but it is still affected by bug #16165 (which is a bit similar). The patch I provided fixes the linking problem. But rrdtool still doesn't work, at least via the RRDs module (it no longer updates the database).

[vinc17@…]

Replying to vinc17@…:

But rrdtool still doesn't work, at least via the RRDs module (it no longer updates the database).

This is in fact a timestamp problem. I've opened bug #17015.

[markd@…]

Does this patch work?

​http://oss.oetiker.ch/rrdtool-trac/attachment/ticket/192/patch-Makefile.PL.diff

[vinc17@…]

FYI, this is the patch I submitted from bug #16165.

[markd@…]

Please test current 1.3.5 rrdtool port. It has several OS X specific bug fixes.

[vinc17@…]

No problem with rrdtool 1.3.5 (except bug #17772).

[(none)]

Milestone Port Bugs deleted