libgetput link error

[davidozog]

When building bale from scratch, with the following changes to install.sh:

• fromscratch=1
• option="--with-upc=no --with-shmem CC=oshcc"

I get the following error during thelibgetput "make" step:

libtool: compile:  oshcc -DHAVE_CONFIG_H -I. -I../../libgetput -g -O2 -DUSE_SHMEM -g -O2 -MT liblibgetput_la-libgetput__c.lo -MD -MP -MF .deps/liblibgetput_la-libgetput__c.Tpo -c libgetput__c.c -o liblibgetput_la-libgetput__c.o >/dev/null 2>&1
mv -f .deps/liblibgetput_la-libgetput__c.Tpo .deps/liblibgetput_la-libgetput__c.Plo
/bin/bash ./libtool    --mode=link      -o liblibgetput.la -rpath /home/dave/Repos/bale/build_ubuntu/lib liblibgetput_la-libgetput__c.lo  
Usage: /home/dave/Repos/bale/build_ubuntu/libgetput/libtool [OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool:   error: unrecognised option: '-o'
Makefile:545: recipe for target 'liblibgetput.la' failed
make[1]: *** [liblibgetput.la] Error 1
make[1]: Leaving directory '/home/dave/Repos/bale/build_ubuntu/libgetput'
Makefile:423: recipe for target 'all' failed
make: *** [all] Error 2
build of libgetput failed!

Strangely, I can avoid this error by setting either of the flags, AM_LDFLAGS or AM_UPCFLAGS, to any string. This is true even separately from the install script:

$ cd libgetput
$ autoreconf -if
$ ./configure --prefix=<install_dir> --with-upc=no --with-shmem CC=oshcc
$ AM_UPCFLAGS=foobar make

I'm not quite sure if this is expected, if I'm doing something wrong, or if there may be some cleaner solution... I can reproduce the issue in Ubuntu and Mac OSX. Thanks in advance for you help!

[jdevinney]

Can you share these same lines of compilation in the case when it succeeds? I am not a libtool expert at all so I doubt I will be able to figure this out. My output in a successful build looks different than what you posted, but I wonder what your successful output looks like. I am using libtool 2.2.6b by the way.

[davidozog]

Sure, here's the successful output (with AM_UPCFLAGS=foobar):

libtool: compile:  oshcc -DHAVE_CONFIG_H -I. -g -O2 -DUSE_SHMEM -g -O2 -MT liblibgetput_la-libgetput__c.lo -MD -MP -MF .deps/liblibgetput_la-libgetput__c.Tpo -c libgetput__c.c -o liblibgetput_la-libgetput__c.o >/dev/null 2>&1
mv -f .deps/liblibgetput_la-libgetput__c.Tpo .deps/liblibgetput_la-libgetput__c.Plo
/bin/bash ./libtool    --mode=link  foobar    -o liblibgetput.la -rpath /home/dave/Repos/bale/libgetput/install/lib liblibgetput_la-libgetput__c.lo  
libtool: link: oshcc -shared  -fPIC -DPIC  .libs/liblibgetput_la-libgetput__c.o      -Wl,-soname -Wl,liblibgetput.so.0 -o .libs/liblibgetput.so.0.0.0
libtool: link: (cd ".libs" && rm -f "liblibgetput.so.0" && ln -s "liblibgetput.so.0.0.0" "liblibgetput.so.0")
libtool: link: (cd ".libs" && rm -f "liblibgetput.so" && ln -s "liblibgetput.so.0.0.0" "liblibgetput.so")
libtool: link: ar cru .libs/liblibgetput.a  liblibgetput_la-libgetput__c.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/liblibgetput.a
libtool: link: ( cd ".libs" && rm -f "liblibgetput.la" && ln -s "../liblibgetput.la" "liblibgetput.la" )
make[1]: Leaving directory '/home/dave/Repos/bale/libgetput'

I'm using libtool version 2.4.6 in this case. I'm no libtool expert either, but I'll let you know if I find anything useful. It's probably a major challenge to support both upcc and oshcc compilers within autotools...

[srirajpaul]

I also have the same issue. @davidozog 's solution works for me.

But it seems the root cause is the use of wrong C-flags in line 544 of Makefile.in (https://github.com/jdevinney/bale/blob/81837f6e3026e5985ebc48a4cc0181adf4d21075/libgetput/Makefile.in#L534).

Even when we use openshmem, seemingly it is using flags "$(AM_V_UPCLD)$(UPCLINK)" instead of "$(AM_V_CCLD)$(LINK). Making this change instead of @davidozog 's solution also works.
AM_V_CCLD and LINK are defined earlier at lines 212 and 209.

Pushing the changes to Makefile.in will not help since it needs to be locally generated by the user while building.

Another easier solution is to set UPC environment variable since the Makefile is using UPC flags. For me after setting 'export UPC=oshcc', building using the command 'install.sh -s -f' works without any other changes.

[jdevinney]

Thanks for this email Sriraj! I am not sure why this is happening, but I have checked in something I hope fixes it. I added a line to each libraries Makefile.am to force it to use the $(LINK) variable rather than the $(UPCLINK) variable. I am not sure why that is necessary for library builds... Can you try checking out bale again and compiling when you get a chance to let me know if this fixes the problem? Jason

…

On Thu, Feb 6, 2020 at 1:27 PM srirajpaul ***@***.***> wrote: I also have the same issue. @davidozog <https://github.com/davidozog> 's solution works for me. But it seems the root cause is the use of wrong C-flags in line 544 of Makefile.in ( https://github.com/jdevinney/bale/blob/81837f6e3026e5985ebc48a4cc0181adf4d21075/libgetput/Makefile.in#L534 ). Even when we use openshmem, seemingly it is using flags "$(AM_V_UPCLD)$(UPCLINK)" instead of "$(AM_V_CCLD)$(LINK). Making this change instead of @davidozog <https://github.com/davidozog> 's solution also works. AM_V_CCLD and LINK are defined earlier at lines 212 and 209. Pushing the changes to Makefile.in will not help since it needs to be locally generated by the user while building. Another solution is to set UPC environment variable since the Makefile is using UPC flags. For me after setting 'export UPC=oshcc', 'install.sh -s -f' works without any other changes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/jdevinney/bale/issues/5?email_source=notifications&email_token=AJKQ2XWW2CJHVLN54KMSR7LRBRJARA5CNFSM4JDVZQY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELAIXQI#issuecomment-583044033>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJKQ2XQ6AFAS3CWMT67WWTDRBRJARANCNFSM4JDVZQYQ> .

[srirajpaul]

@jdevinney This checkin (Commit id 8bf9d5b ) fixed the problem. We can close #5 . Thank you.