[SoX-devel] SoX's master branch currently FTBFS

Discussion:

Pascal Giard

2015-02-27 04:34:05 UTC

Wanting to test the timestamp removal pushing committing the changes,
I first tried to build the master branch.

However, it fails with the following:
$ /bin/sh ../libtool --silent --tag=CC --silent --mode=link gcc
-Wtraditional-conversion -g -O2 -fstack-protector -Wall -W
-Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp
-avoid-version -module -Wl,-z,defs -o libsox_fmt_flac.la -rpath
/usr/local/lib/sox flac.lo libsox.la -lFLAC -lvorbisenc -lvorbisfile
-lvorbis -logg -lm
.libs/flac.o: In function `decoder_read_callback':
/some/path/sox/src/flac.c:63: undefined reference to `lsx_error'

Same occurs for libsox_fmt_mp3.la.

A quick glance at the changes introduced in configure.ac recently-ish
does not being anything obvious to me. Before I try to further
investigate what's happening, do you guys have an idea? How come it's
only showing up now and in master. The debian branch compiles fine.

-Pascal

--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca)

Chris Bagwell

2015-02-27 05:11:54 UTC

Permalink

Nothing jumps out at me other to to verify you reran autoreconf since I
notice you've shown verbose output and now you have to go out of your way
with 'make V=1' to see that libtool line.

lsx_error is referenced by that flac.lo and symbol should be in libsox.la
(from format_i.o) that is listed right after it... so sounds like a badly
generated libsox.

The only new compiler option I recall is that -fstack-protector but that
should affect symbols references.

Chris

Post by Pascal Giard
Wanting to test the timestamp removal pushing committing the changes,
I first tried to build the master branch.
$ /bin/sh ../libtool --silent --tag=CC --silent --mode=link gcc
-Wtraditional-conversion -g -O2 -fstack-protector -Wall -W
-Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp
-avoid-version -module -Wl,-z,defs -o libsox_fmt_flac.la -rpath
/usr/local/lib/sox flac.lo libsox.la -lFLAC -lvorbisenc -lvorbisfile
-lvorbis -logg -lm
/some/path/sox/src/flac.c:63: undefined reference to `lsx_error'
Same occurs for libsox_fmt_mp3.la.
A quick glance at the changes introduced in configure.ac recently-ish
does not being anything obvious to me. Before I try to further
investigate what's happening, do you guys have an idea? How come it's
only showing up now and in master. The debian branch compiles fine.
-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunitÃ©/LACIME: Ãcole de technologie supÃ©rieure (http://www.comunite.ca)
ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca)
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for
all
things parallel software development, from weekly thought leadership blogs
to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
SoX-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sox-devel

Pascal Giard

2015-02-27 15:02:24 UTC

Permalink

Hi Chris!

Post by Chris Bagwell
Nothing jumps out at me other to to verify you reran autoreconf since I
notice you've shown verbose output and now you have to go out of your way
with 'make V=1' to see that libtool line.

I did go out of my way as I was trying to figure out what's going on.
And yes, I have ran "autoreconf -i" before calling "make -j4 V=1 clean all".

Post by Chris Bagwell
lsx_error is referenced by that flac.lo and symbol should be in libsox.la
(from format_i.o) that is listed right after it... so sounds like a badly
generated libsox.

Hmm.. I'll have to carefully check again.
Trying from a clean git clone on one of my works machine, compilation
also fails at the very same place.

Are you able to reproduce the error on your end as well?

Post by Chris Bagwell
The only new compiler option I recall is that -fstack-protector but that
should affect symbols references.

Nope, that shouldn't be related.

-Pascal

Chris Bagwell

2015-02-28 19:04:44 UTC

Permalink

Post by Pascal Giard

Post by Chris Bagwell
lsx_error is referenced by that flac.lo and symbol should be in

libsox.la

Post by Chris Bagwell
(from format_i.o) that is listed right after it... so sounds like a badly
generated libsox.

Hmm.. I'll have to carefully check again.
Trying from a clean git clone on one of my works machine, compilation
also fails at the very same place.
Are you able to reproduce the error on your end as well?

No, I couldn't reproduce. I tried on latest Fedora and OSX with no issues
seen.

My Fedora has version 2.4.2 of libtool btw. Thats only other thing I
could think of that could cause fake link issues.

Chris

Pascal Giard

2015-03-02 15:43:12 UTC

Permalink

Hi Chris,

Post by Chris Bagwell

Post by Pascal Giard

Post by Chris Bagwell
lsx_error is referenced by that flac.lo and symbol should be in libsox.la
(from format_i.o) that is listed right after it... so sounds like a badly
generated libsox.

Hmm.. I'll have to carefully check again.
Trying from a clean git clone on one of my works machine, compilation
also fails at the very same place.
Are you able to reproduce the error on your end as well?

No, I couldn't reproduce. I tried on latest Fedora and OSX with no issues
seen.
My Fedora has version 2.4.2 of libtool btw. Thats only other thing I could
think of that could cause fake link issues.

First, I want to apologize. I was trying to build "à la" Debian by
using "--with-dyn-default" and I didn't tell you. How could have you
guessed?!

Compilation with default options works. Compilation with
"--with-dyn-default" doesn't. It's been broken for quite a while
actually!

Using git bisect, I was able to quickly identify the culprit.
FWIW, I ran the following:
git bisect start HEAD sox-14.4.1
git bisect run sh -c 'autoreconf -i && ./configure --with-dyn-default
&& make V=1 -j8'

And got:
5c58413544fd600bf12fdc54fa9648f0bc1ea860 is the first bad commit
commit 5c58413544fd600bf12fdc54fa9648f0bc1ea860
Author: Ulrich Klauer <***@chirlu.de>
Date: Sat Mar 9 02:23:55 2013 +0100

Don't export (most) internal libsox symbols

Ideally, libsox should only export those symbols that are part of the
official API, i.e. those with the sox_ prefix. This isn't easily
possible, though, because certain internal (lsx_) symbols are used by
SoX-the-application and by the plugin modules in case of a modularized
build. As a step in the right direction, this change exposes only the
symbols actually needed, hiding about 300 (90 %) of the lsx_ symbols.

(Relevant tracker item: FR 2214694.)

:100644 100644 2d6e5cd51a6666f9b44f053d105a8a662fb47b5c
2d35eec8ca917f84202eee6a7e4669f5fd796e53 M ChangeLog
:040000 040000 7418f7851edebdc139af00b451d475ac871b3b72
9193c7eb2183479d4107ff85cd75c738eb61d15b M src

-Pascal

Eric Wong

2016-01-10 01:53:47 UTC

Permalink

Hi Pascal,

I found a fix to this problem by adding lsx_error and lsx_flush
to the regular expression (and I needed to "make clean" before
rebuilding, so there's likely still a smaller build problem there).

Pushed to the "ew/dyn-default-fix" branch on git://80x24.org/sox
(as well as my "pu" (proposed updates) branch there)

The size of regexp is difficult to maintain and perhaps we should
use -export-symbols SYMFILE instead...

-------------------------8<-------------------------
Subject: [PATCH] fix build with --with-dyn-default

This was broken in commit 5c58413544fd600bf12fdc54fa9648f0bc1ea860
("Don't export (most) internal libsox symbols")

and noticed by both Pascal Giard and myself:
http://mid.gmane.org/CAJNNDmk0oU=haP3DmVMAG6mtNCg=cO=7ROqx-eaFo2LxkQt7+***@mail.gmail.com
http://mid.gmane.org/***@dcvr.yhbt.net
---
src/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 7cceaaf..6d6acf5 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -95,7 +95,7 @@ libsox_la_LIBADD += @GOMP_LIBS@

libsox_la_CFLAGS = @WARN_CFLAGS@
libsox_la_LDFLAGS = @APP_LDFLAGS@ -version-info @SHLIB_VERSION@ \
- -export-symbols-regex '^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|fail_errno|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$$'
+ -export-symbols-regex '^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|error|fail_errno|filelength|find_(enum_(text|value)|file_extension)|flush|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$$'

if HAVE_WIN32_LTDL
libsox_la_SOURCES += win32-ltdl.c win32-ltdl.h

--
EW

Måns Rullgård

2016-01-10 01:56:25 UTC

Permalink

Post by Eric Wong
Hi Pascal,
I found a fix to this problem by adding lsx_error and lsx_flush
to the regular expression (and I needed to "make clean" before
rebuilding, so there's likely still a smaller build problem there).
Pushed to the "ew/dyn-default-fix" branch on git://80x24.org/sox
(as well as my "pu" (proposed updates) branch there)
The size of regexp is difficult to maintain and perhaps we should
use -export-symbols SYMFILE instead...

It's horrible as is, especially with all the nested alternatives. A
file with a symbol per line would be much cleaner.

--
Måns Rullgård

Pascal Giard

2016-01-10 16:00:35 UTC

Permalink

Hi guys,
allow me to be brief.

As you might have guessed from my lack of activity on SoX's mailing
lists, I'm terribly busy.

I don't have time to dedicate to SoX right now and I don't see that
improving in the next 4 to 5 months either.

I'm sorry... :-/
I wish someone could step up to give a hand...

-Pascal

Post by MÃ¥ns RullgÃ¥rd

It's horrible as is, especially with all the nested alternatives. A
file with a symbol per line would be much cleaner.

--
Måns Rullgård
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
SoX-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sox-devel

--
Homepage (http://www.ece.mcgill.ca/~pgiard1)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca)

Måns Rullgård

2016-01-12 10:59:20 UTC

Permalink

Post by Pascal Giard
Hi guys,
allow me to be brief.
As you might have guessed from my lack of activity on SoX's mailing
lists, I'm terribly busy.
I don't have time to dedicate to SoX right now and I don't see that
improving in the next 4 to 5 months either.
I'm sorry... :-/
I wish someone could step up to give a hand...

I'd be happy to. IIRC Eric Wong also said he'd be willing to step in
for a while. How can we help?

--
Måns Rullgård