Issue 30: Build fails on Ubuntu 11.10 (changed ld default behavior)

[miguno]

This patch explicitly sets the ld option '--no-as-needed'. In Ubuntu
11.10, the default behavior of ld was changed to '--as-needed', which
breaks the src/native/configure script and its detection of the native
liblzo2 library.

More information is available at:
https://github.com/kevinweil/hadoop-lzo/issues/33

[rangadi]

looks good. This option exists in older ld as well, right?

[miguno]

As far as I know, yes. I have seen that even ld on ancient RHEL5 comes with that option. From what I understand only the default behavior was changed but the options (--no-as-needed and --as-needed) already existed since some time.

[dvryaboy]

Michael, as it turns out, this breaks the build on OS X Lion:

configure:3360: checking whether the C compiler works
configure:3382: /usr/bin/gcc-4.2 -Wl,--no-as-needed conftest.c >&5
ld: unknown option: --no-as-needed
collect2: ld returned 1 exit status

Suggestions?

[miguno]

Hi Dmitriy,

I don't have a Mac at work to investigate this directly, but I do have some follow-up questions:

1) Does ld on Mac (Lion) work "correctly" out of the box? In other words, does it by default also link libraries which are specified on the command line but never actually used in the C code? (This would be the same behavior as running ld on Linux with '--no-as-needed') If that's the case, then maybe updating build.xml with a switch could work, where the switch simply disables adding the LDFLAGS setting.

This is the relevant section in build.xml:

    <exec dir="${build.native}" executable="sh" failonerror="true">
       <env key="OS_NAME" value="${os.name}"/>
       <env key="OS_ARCH" value="${os.arch}"/>
       <env key="LDFLAGS" value="-Wl,--no-as-needed"/>
       ...
    </exec>

In Maven we could use profiles to accomplish this pretty easily, but since hadoop-lzo uses ant I can't tell you off the top of my head how such a switch could be implemented. That said, I noticed the following snippet in build.xml:

  <exec executable="sed" inputstring="${os.name}" 
        outputproperty="nonspace.os">
     <arg value="s/ /_/g"/>
  </exec>

If properties in ant can be dynamically set in this way, maybe this feature can also be used to set/unset LDFLAGS depending on, coincidentally, a environment value such as os.arch or os.name? Note that as far as I remember ant is running inside a JVM, and hence it will only detect the architecture of the JVM.

I found a blog post of someone trying exactly this using Ant properties:
How to make a conditional decision in an Ant build script based on operating system

As I said I don't have a Mac here so I can't test it myself, but I think this should work.

2) Alternatively, the "test" C code that will be used to check for liblzo2 could be changed in a way that it actually does call liblzo2 in some way. Then ld would be forced to link liblzo2 in any case.

echo 'int main(int argc, char **argv){return 0;}' > conftest.c

The above snippet is the relevant line in src/native/configure which would have to be updated to use liblzo2 in some way. I'm not overly familiar with C (and even that's an understatement, heh) how this would be done in the best way, though.

Does this help?
Michael

PS: Oh, maybe the same issue with ld exist not only on Mac but maybe on other BSD-based systems, too?

[miguno]

Hi Dmitriy, has this issue for Mac OS X been solved?

[dvryaboy]

Yes, Raghu fixed it in the latest release

On Jan 13, 2012, at 1:49 AM, "Michael G. Noll"reply@reply.github.com wrote:

Hi Dmitriy, has this issue for Mac OS X been solved?

---

Reply to this email directly or view it on GitHub:
https://github.com/kevinweil/hadoop-lzo/pull/34#issuecomment-3477649