Opened 9 years ago

Closed 8 years ago

#745 closed defect (fixed)

Symbol not found: _bam_nt16_rev_table

Reported by: Peter Owned by: Peter
Priority: major Milestone: yat 0.10.2
Component: omic Version: 0.10.1
Keywords: Cc:

Description

Ideally we should use that table, but when not available (check at configure time) fall back on home brew.

Attachments (2)

link_test.sh (1.9 KB) - added by Peter 8 years ago.
trimmed down test
link_test.2.sh (1.9 KB) - added by Peter 8 years ago.
using whole archive

Download all attachments as: .zip

Change History (32)

comment:1 Changed 9 years ago by Peter

Status: newassigned

comment:2 Changed 9 years ago by Peter

My first analysis does not make sense, so I need more info to get convinced what the problem is.

1) Test fails at link time, not runtime?

2) BamRead.cc compiles so presume your bam.h declares 'bam_nt16_rev_table'.

3) Do you have dynamic lib or only static libbam.a?

4) Is bam_nt16_rev_table is libbam? I.e., what is output of 'nm /path/to/libbam/ | grep nt16_rev '?

5) What is output of 'rm -f test/bam_iterator; make test/bam_iterator V=1'?

comment:3 Changed 9 years ago by Peter

(In [2972]) refs #745. Implement a workaround when bam_nt16_rev_table is not available in -lbam.

comment:4 in reply to:  2 Changed 9 years ago by Jari Häkkinen

Replying to peter: I cannot recreate the problem any more and I have no good explanation for why. The machine I am testing is very fresh and packages are added now and then to resolve issues with missing packages. Maybe soe dynamic linker search path got fixed? I am not the sysadm of the machine I use for testing so I cannot account for changes on the machine.

The problem was during run-time, i.e., the missing table could not be located. BamRead?.cc compiled just fine and I have a static libbam only and it is the latest version 0.1.18. The installed libbam does contain the table.

I think this ticket can be closed especially since you added a fix to support old libbams.

Sorry for the noise.

comment:5 Changed 9 years ago by Peter

Resolution: fixed
Status: assignedclosed

comment:6 Changed 9 years ago by Jari Häkkinen

Resolution: fixed
Status: closedreopened

I confused my different test machines and have to reopen this ticket. The issue persists on my mac but in this example it is not the rev_table causing problems.

Compiling as suggested above

beppe:yat> rm -f test/bam_iterator; make test/bam_iterator V=1
/bin/sh ./libtool  --tag=CXX   --mode=link g++ -O3   -L/opt/local/lib  \
  -o test/bam_iterator test/bam_iterator.o yat/libyat.la test/libyattest.la \
  -lbam -lz -lgsl -lcblas   -lboost_thread-mt -lboost_system-mt 
libtool: link: g++ -O3 -o test/.libs/bam_iterator test/bam_iterator.o \
  -Wl,-bind_at_load  -L/opt/local/lib yat/.libs/libyat.dylib test/.libs/libyattest.a \
  /Users/jari/projects/yat/yat/.libs/libyat.dylib -lbam -lz /opt/local/lib/libgsl.dylib \
  -lm -lcblas -lboost_thread-mt -lboost_system-mt

creates a binary that fails at runtime

beppe:yat> ./test/bam_iterator -v
running '/Users/jari/projects/yat/test/.libs/bam_iterator' in
'test/testSubDir/bam_iterator' entries in ../../data/foo.sorted.bam: 800
entries in bam_iterator.bam: 800
dyld: lazy symbol binding failed: Symbol not found: _bam_index_destroy
  Referenced from: /Users/jari/projects/yat/yat/.libs/libyat.8.dylib
  Expected in: flat namespace

dyld: Symbol not found: _bam_index_destroy
  Referenced from: /Users/jari/projects/yat/yat/.libs/libyat.8.dylib
  Expected in: flat namespace

Trace/BPT trap: 5

The dynamic library dependencies are

beppe:yat> otool -L test/.libs/bam_iterator 
test/.libs/bam_iterator:
	/usr/local/lib/libyat.8.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
	/opt/local/lib/libgsl.0.dylib (compatibility version 17.0.0, current version 17.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)

where /usr/local/lib/libyat.8.dylib (compatibility version 9.0.0, current version 9.0.0) is surprising since there is no libyat intalled in /usr/local. Looking for bam_index_* functions:

beppe:yat> nm test/.libs/bam_iterator | grep bam_index

returns nothing. But

beppe:omic> nm BamFile.o | grep bam_in
                 U _bam_index_destroy
                 U _bam_index_load
beppe:yat> nm yat/.libs/libyat.dylib | grep bam_index
                 U _bam_index_destroy
                 U _bam_index_load

shows that there are references to the functions. And finally

beppe:yat> nm /opt/local/lib/libbam.a | grep bam_index_destroy 
0000000000000960 T _bam_index_destroy
0000000000008bd8 S _bam_index_destroy.eh
                 U _bam_index_destroy

show that it exists in libbam.a. Interestingly looking for a related bam function and the rev_table shows

beppe:yat> nm test/.libs/bam_iterator | grep bam_header
0000000100008780 T _bam_header_destroy
000000010000adf0 T _bam_header_dup
0000000100008540 T _bam_header_init
0000000100008560 T _bam_header_read
00000001000083a0 T _bam_header_write
beppe:yat> nm test/.libs/bam_iterator | grep rev_table 
00000001000178c0 D _bam_nt16_rev_table

shows that they are included in the bam_iterator binary.

Clearly the bam_index_destroy should also appear in the bam_iterator binary. Why does it not do that?

comment:7 Changed 9 years ago by Peter

Looks like a bug in your ld. Do you have another linker you can try. One old libtool thread mentioned similar problem related to templates and and flat namespace on OSX. There, they claimed it could be solved by setting MAOSX_DEPLOYMENT_TARGET=10.3.

  • Which OSX is this on?
  • What is 'grep "^host=" config.log'?
  • What gives 'grep "^allow_undefined" libtool'?
  • What gives 'printenv | grep MACOSX_DEPLOYMENT_TARGET'?

Not sure why it works on my mac, though; it's older. I have, however, built libbam myself with gcc, and not installed via macport. Only difference I can see except that I have older compiler, linker, etc.

comment:8 in reply to:  7 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

Looks like a bug in your ld. Do you have another linker you can try.

I don't think so. I'll see and call you back.

  • Which OSX is this on?

OSX 10.8 and 10.7 (a.k.a., Mountain Lion and Lion)

The responses below is from my Lion machine:

  • What is 'grep "^host=" config.log'?
host='x86_64-apple-darwin11.4.2'
  • What gives 'grep "^allow_undefined" libtool'?
allow_undefined_flag="\${wl}-undefined \${wl}dynamic_lookup"
allow_undefined_flag="\${wl}-undefined \${wl}dynamic_lookup"
  • What gives 'printenv | grep MACOSX_DEPLOYMENT_TARGET'?

Nothing

Not sure why it works on my mac, though; it's older. I have, however, built libbam myself with gcc, and not installed via macport. Only difference I can see except that I have older compiler, linker, etc.

I'll try to uninstall macports samtools and install from source.

comment:9 in reply to:  8 Changed 8 years ago by Jari Häkkinen

Replying to jari:

Not sure why it works on my mac, though; it's older. I have, however, built libbam myself with gcc, and not installed via macport. Only difference I can see except that I have older compiler, linker, etc.

I'll try to uninstall macports samtools and install from source.

I've installed samtools from source but the problem does not go away.

comment:10 in reply to:  8 ; Changed 8 years ago by Jari Häkkinen

Replying to jari:

  • What gives 'printenv | grep MACOSX_DEPLOYMENT_TARGET'?

Nothing

I did

# export MACOSX_DEPLOYMENT_TARGET=10.3

and get

/usr/include/AvailabilityMacros.h:109:14: warning: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid.

so that path seems closed for me.

comment:11 in reply to:  10 ; Changed 8 years ago by Peter

Replying to jari:

Replying to jari:

  • What gives 'printenv | grep MACOSX_DEPLOYMENT_TARGET'?

Nothing

I did

# export MACOSX_DEPLOYMENT_TARGET=10.3

and get

/usr/include/AvailabilityMacros.h:109:14: warning: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid.

so that path seems closed for me.

What about exporting 10.4?

Changed 8 years ago by Peter

Attachment: link_test.sh added

trimmed down test

comment:12 Changed 8 years ago by Peter

I've added a trimmed down case that I believe pinpoints the problem. Can you please try it on a new OSX (it works on OSX 10.4). The test creates a static C library. A dynamic C++ library with a class Bar that inherits from a templatized base class calls a function in static C library. Then we creates a program that links in both libraries but only calls the C++ library explicitly (but obviously the static C library indirectly).

comment:13 in reply to:  12 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

I've added a trimmed down case that I believe pinpoints the problem. Can you please try it on a new OSX (it works on OSX 10.4).

I get

libtool: link: g++ -g -O2 -o .libs/baz baz.o -Wl,-bind_at_load \
    ../bar/.libs/libbar.dylib ../foo/libfoo.a
dyld: lazy symbol binding failed: Symbol not found: _foo_version
  Referenced from: /Users/jari/projects/yat/bar/.libs/libbar.0.dylib
  Expected in: flat namespace

dyld: Symbol not found: _foo_version
  Referenced from: /Users/jari/projects/yat/bar/.libs/libbar.0.dylib
  Expected in: flat namespace

./link_test.sh: line 147: 80434 Trace/BPT trap: 5       ./baz

comment:14 in reply to:  11 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

What about exporting 10.4?

Compilation works but make check fails.

comment:15 in reply to:  14 Changed 8 years ago by Peter

Replying to jari:

Replying to peter:

What about exporting 10.4?

Compilation works but make check fails.

Same behaviour in other words.

comment:16 in reply to:  13 ; Changed 8 years ago by Peter

Replying to jari:

Replying to peter:

I've added a trimmed down case that I believe pinpoints the problem. Can you please try it on a new OSX (it works on OSX 10.4).

I get

libtool: link: g++ -g -O2 -o .libs/baz baz.o -Wl,-bind_at_load \
    ../bar/.libs/libbar.dylib ../foo/libfoo.a
dyld: lazy symbol binding failed: Symbol not found: _foo_version
  Referenced from: /Users/jari/projects/yat/bar/.libs/libbar.0.dylib
  Expected in: flat namespace

dyld: Symbol not found: _foo_version
  Referenced from: /Users/jari/projects/yat/bar/.libs/libbar.0.dylib
  Expected in: flat namespace

./link_test.sh: line 147: 80434 Trace/BPT trap: 5       ./baz

Same as for the test program then, which means we have a test case that is easier to play around with. I have no ideas right no, though, except testing what happens if removing templates in bar or removing usage of libtool in baz. The former should be straightforward, the latter less so.

comment:17 in reply to:  16 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

Same as for the test program then, which means we have a test case that is easier to play around with. I have no ideas right no, though, ...

I am running out of ideas too. Searching the Webb doesn't help either. Anyhow, the below exercise shows that there is no dependency too libfoo.a

beppe:yat> otool -L foo/libfoo.a 
Archive : foo/libfoo.a
foo/libfoo.a(foo.o):
beppe:yat> otool -L bar/.libs/libbar.0.dylib 
bar/.libs/libbar.0.dylib:
	/usr/local/lib/libbar.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
beppe:yat> otool -L baz/.libs/baz            
baz/.libs/baz:
	/usr/local/lib/libbar.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
beppe:yat> otool -L bar/.libs/libbar.a       
Archive : bar/.libs/libbar.a
bar/.libs/libbar.a(bar.o):

Either libbar.0.dylib or baz should have a dependency to libfoo.a but neither have. How is the linker supposed to find the missing function? Maybe things get better if foo is also created as a dynamic library?

Continuing

beppe:yat> cd baz/
beppe:baz> g++ -g -O2 -o baztest baz.o ../bar/.libs/libbar.dylib ../foo/libfoo.abeppe:baz> ./baztest 
dyld: Library not loaded: /usr/local/lib/libbar.0.dylib
  Referenced from: /Users/jari/projects/yat/baz/./baztest
  Reason: image not found
Trace/BPT trap: 5
beppe:baz> g++ -g -O2 -o baztest baz.o ../foo/libfoo.a ../bar/.libs/libbar.dylib         
beppe:baz> ./baztest 
dyld: Library not loaded: /usr/local/lib/libbar.0.dylib
  Referenced from: /Users/jari/projects/yat/baz/./baztest
  Reason: image not found
Trace/BPT trap: 5
beppe:baz> g++ -g -O2 -o baztest baz.o ../bar/.libs/libbar.a ../foo/libfoo.a
beppe:baz> ./baztest 
3.14
beppe:baz> g++ -g -O2 -o baztest baz.o ../foo/libfoo.a ../bar/.libs/libbar.a    
beppe:baz> ./baztest 
3.14

The above shows that if static libraries only are used then I get a usable binary. Of course, no libtool used then.

I even removed macports just to make sure that there isn't a clash between Xcode stuff and macports. Assuming I was able to remove all macports the conlusion is that Xcode only stuff behaves the same.

I am not sure where this is going, I just wanted to write down some notes.

I don't think it is a C/C++ issue, foo might just as well be written in C++ and the problem would persist. I'd say that the problem is that there is no pointer to the libfoo.a dependency.

comment:18 in reply to:  17 ; Changed 8 years ago by Peter

Replying to jari:

I am running out of ideas too. Searching the Webb doesn't help either. Anyhow, the below exercise shows that there is no dependency too libfoo.a

beppe:yat> otool -L foo/libfoo.a 
Archive : foo/libfoo.a
foo/libfoo.a(foo.o):
beppe:yat> otool -L bar/.libs/libbar.0.dylib 
bar/.libs/libbar.0.dylib:
	/usr/local/lib/libbar.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
beppe:yat> otool -L baz/.libs/baz            
baz/.libs/baz:
	/usr/local/lib/libbar.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
beppe:yat> otool -L bar/.libs/libbar.a       
Archive : bar/.libs/libbar.a
bar/.libs/libbar.a(bar.o):

Either libbar.0.dylib or baz should have a dependency to libfoo.a but neither have. How is the linker supposed to find the missing function?

No, there shouldn't bee any dependency to libfoo. The dynamic loader only loads dynamic libraries; it does not load static libraries suc as libfoo.a. The linker, however, should link in everything in libfoo.a into baz. On my mac I have

$ nm baz | grep foo
00002e27 T _foo_version

and no other dependencies to libfoo.a.

Maybe things get better if foo is also created as a dynamic library?

I suspect it works if there is a libfoo.dylib. It would be good to know so we can suggest that users to have a libbam.dylib. Likewise I suspect it works if only static libs exist, which means users can build yat with ./configure --disable-shared.

Continuing

beppe:yat> cd baz/
beppe:baz> g++ -g -O2 -o baztest baz.o ../bar/.libs/libbar.dylib ../foo/libfoo.abeppe:baz> ./baztest 
dyld: Library not loaded: /usr/local/lib/libbar.0.dylib
  Referenced from: /Users/jari/projects/yat/baz/./baztest
  Reason: image not found
Trace/BPT trap: 5
beppe:baz> g++ -g -O2 -o baztest baz.o ../foo/libfoo.a ../bar/.libs/libbar.dylib         
beppe:baz> ./baztest 
dyld: Library not loaded: /usr/local/lib/libbar.0.dylib
  Referenced from: /Users/jari/projects/yat/baz/./baztest
  Reason: image not found
Trace/BPT trap: 5
beppe:baz> g++ -g -O2 -o baztest baz.o ../bar/.libs/libbar.a ../foo/libfoo.a
beppe:baz> ./baztest 
3.14
beppe:baz> g++ -g -O2 -o baztest baz.o ../foo/libfoo.a ../bar/.libs/libbar.a    
beppe:baz> ./baztest 
3.14

The above shows that if static libraries only are used then I get a usable binary. Of course, no libtool used then.

Running binaries that have been linked against dylibs not yet installed is doomed to fail. You need to set all sort of env vars to get that to work otherwise the runtime loader will look for the dylibs where there are expected to be installed. That's why test programs are not binaries but wrapper script that call the binaries in test/.libs/.

I even removed macports just to make sure that there isn't a clash between Xcode stuff and macports. Assuming I was able to remove all macports the conlusion is that Xcode only stuff behaves the same.

I am not sure where this is going, I just wanted to write down some notes.

I don't think it is a C/C++ issue, foo might just as well be written in C++ and the problem would persist.

I agree.

I'd say that the problem is that there is no pointer to the libfoo.a dependency.

I disagree. The problem is that the linker is not linking in function foo_version into baz.

I'll check with the libtool folks if they have any suggestion. Otherwise, I guess we just add a note in README and close as wontfix.

comment:19 in reply to:  18 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

Replying to jari:

Either libbar.0.dylib or baz should have a dependency to libfoo.a but neither have. How is the linker supposed to find the missing function?

No, there shouldn't bee any dependency to libfoo. The dynamic loader only loads dynamic libraries; it does not load static libraries suc as libfoo.a. The linker, however, should link in everything in libfoo.a into baz. On my mac I have

$ nm baz | grep foo
00002e27 T _foo_version

and no other dependencies to libfoo.a.

But how is this done? Where does _foo_version get included from into your binary? Does it reside in libbar or in libfoo? Obviously it is in libfoo but how does your linker understand to include _foo_version. This is what I mean that there should be a reference to libfoo ... at some stage the compiler or a linker must assemble all non-dynamic parts required into the final binary. And since there is dynamic linking involved later there must be some smart lookups made at some stage to include whatever is needed from the static libraries.

I suspect it works if there is a libfoo.dylib. It would be good to know so we can suggest that users to have a libbam.dylib. Likewise I suspect it works if only static libs exist, which means users can build yat with ./configure --disable-shared.

yat checks works when shared libraries are disabled. I suspect that the samtools build script does not support shared builds.

Running binaries that have been linked against dylibs not yet installed is doomed to fail. You need to set all sort of env vars to get that to work otherwise the runtime loader will look for the dylibs where there are expected to be installed. That's why test programs are not binaries but wrapper script that call the binaries in test/.libs/.

Of course, the effect stays the same even with the proper set up of environment ... the produced binary using libfoo.dylib does not work.

I'll check with the libtool folks if they have any suggestion. Otherwise, I guess we just add a note in README and close as wontfix.

Is this a general problem or are we doing something wrong? There are very few references on the Internet to similar issues. I supposed would never have notice this if samtools would have provided a shared library. My conclusion is that all yat support libraries are available in shared form ... something I never reflected on.

Will it be possible for me to build shared library based binaries using yat and samtools, or do I have to create static only binaries?

Resolving this as a wontfix is very unsatisfactory. It implies that I must build yat as static-only to get the tests through. And something is itching ...

comment:20 in reply to:  19 Changed 8 years ago by Peter

Replying to jari:

But how is this done? Where does _foo_version get included from into your binary? Does it reside in libbar or in libfoo? Obviously it is in libfoo but how does your linker understand to include _foo_version.

Not in libbar obviously as it i created without knowing about libfoo (knows about foo.h only). But baz is created with

g++ -g -O2 -o .libs/baz baz.o -Wl,-bind_at_load  ../bar/.libs/libbar.dylib ../foo/libfoo.a

which says I might use symbols and libfoo and since libfoo is static do link them into baz. My linker even goes into libbar.dylib and detectes that foo_version is used. Your linker is not doing that step. If foo_version was called from baz directly, I'd be surprised if your linker failed. The fact that Bar inherits from a template class might contribute to teh confusion.

This is what I mean that there should be a reference to libfoo ... at some stage the compiler or a linker must assemble all non-dynamic parts required into the final binary. And since there is dynamic linking involved later there must be some smart lookups made at some stage to include whatever is needed from the static libraries.

See above. I still think it's a bug in your linker unless our -bind_at_load is a pilot error.

I suspect it works if there is a libfoo.dylib. It would be good to know so we can suggest that users to have a libbam.dylib. Likewise I suspect it works if only static libs exist, which means users can build yat with ./configure --disable-shared.

yat checks works when shared libraries are disabled.

Good to know. If installing libyat with --disable-shared, do remember to remove all old libyat.dylibs or the linker will choose them rather than the newly installed libyat.a.

I suspect that the samtools build script does not support shared builds.

samtools' Makefile contains a dylib target that I've used succesfully.

Running binaries that have been linked against dylibs not yet installed is doomed to fail. You need to set all sort of env vars to get that to work otherwise the runtime loader will look for the dylibs where there are expected to be installed. That's why test programs are not binaries but wrapper script that call the binaries in test/.libs/.

Of course, the effect stays the same even with the proper set up of environment ... the produced binary using libfoo.dylib does not work.

I'll check with the libtool folks if they have any suggestion. Otherwise, I guess we just add a note in README and close as wontfix.

Is this a general problem or are we doing something wrong? There are very few references on the Internet to similar issues. I supposed would never have notice this if samtools would have provided a shared library. My conclusion is that all yat support libraries are available in shared form ... something I never reflected on.

GSL and Boost come as shared, of course. Boost doesn't provide static libs IIRC. I guess it's not common to link against a mixture of static and shared libs. I doubt it can be that general that mixing shared and static will always fail on (newer) OSX; it must be that we've hit a special case in our code that confuses tha linker to not parse the shared lib entirely to find symbols foo_version. Templates?

Will it be possible for me to build shared library based binaries using yat and samtools, or do I have to create static only binaries?

Install a libbam.dylib. That should kill the issue.

Resolving this as a wontfix is very unsatisfactory. It implies that I must build yat as static-only to get the tests through. And something is itching ...

Sure. But when next release is knocking on the door, can't really hold it waiting for a solution of this ticket since we have no real clue.

comment:21 Changed 8 years ago by Peter

Here is a discussion from 2007 that I think describes the problem: http://lists.gnu.org/archive/html/libtool-patches/2007-02/msg00063.html

Changed 8 years ago by Peter

Attachment: link_test.2.sh added

using whole archive

comment:22 Changed 8 years ago by Peter

I got the following suggestion from the libtool list and I have updated the link_test script accordingly. Jari can you check if solves the issue for you. Hopefully it works, but it is a bit ugly and ideally the syntax should only be used when needed which would require ticket #737.

comment:23 Changed 8 years ago by Peter

With apple linker (Tiger) I get:

/usr/bin/ld: unknown flag: -whole-archive

so I guess that is GNU specific feature. Another dead end, it seems.

comment:24 Changed 8 years ago by Peter

Can you try using flat namespace, i.e., linking with

make clean [or at least remove all linked stuff]
make check LDFLAGS=-Wl,-flat_namespace

comment:25 in reply to:  24 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

Can you try using flat namespace, i.e., linking with

make clean [or at least remove all linked stuff]
make check LDFLAGS=-Wl,-flat_namespace

All 98 tests pass!

comment:26 in reply to:  23 Changed 8 years ago by Jari Häkkinen

Replying to peter: I get the same. A few lines before the barf I get a warning but it is probably expected

/bin/sh ./libtool --tag=CXX   --mode=link g++  -g -O2 -Wl,-whole-archive ../foo/libfoo.a \
        -Wl,-no-whole-archive  -o libbar.la -rpath /usr/local/lib bar.lo  

*** Warning: Linking the shared library libbar.la against the
*** static library ../foo/libfoo.a is not portable!

comment:27 in reply to:  25 Changed 8 years ago by Peter

Replying to jari:

Replying to peter:

Can you try using flat namespace, i.e., linking with

make clean [or at least remove all linked stuff]
make check LDFLAGS=-Wl,-flat_namespace

All 98 tests pass!

Great! Then we should only add that flag in configure.ac when appropriate. For now it seems least intrusive to just add the flag when $host_os=darwin*, or do we have more specifics than that? More elaborate solutions that depends on testing if this is needed depends on #737. We could check if the flag is needed both when creating libyat and linking executables, or should we just use it in both cases? Linking executables means it must propagate to yat-config as well.

comment:28 Changed 8 years ago by Peter

(In [3003]) prefer flat_namespace on darwin (OSX). refs #745

comment:29 Changed 8 years ago by Peter

(In [3008]) avoid spurious test error: use yat-config --ldflags when linking. refs #745

comment:30 Changed 8 years ago by Peter

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.