Re: [Discuss-gnuradio] I can't get my gsl to link

[Alan Corey]

Ah, ok:
which ld
/usr/bin/ld
file /usr/bin/ld
/usr/bin/ld: symbolic link to /usr/bin/aarch64-linux-gnu-ld.gold
ld --version
GNU gold (GNU Binutils for Debian 2.28) 1.14

I remembered as soon as I really thought about it, I built this
Firefox on here a month or so ago when I first got the machine.  You
sort of need to fiddle with gold and ninja. Mostly it's been a drop-in
replacement, this is the first problem I've had with it.  But by the
gold man page:
       --verbose
              Alias for --debug=files
so it was always expecting a file name following.  And:
ld --verbose
ld: fatal error: no input files

Maybe there's a way to see where gold searches, don't see it in the man page.

This may well explain my Gnuradio problem.  Everything but gsl seems
to work though.  I'll see if I can dig up the original ld.

Thanks for the Osmocom link.  I gather Osmocom can contain librtlsdr?
Maybe rtlsdr isn't usable as a Gnuradio source.   librtlsdr I've done
some playing around with trying to write a GUI sdr program that
doesn't use Gnuradio for small (mainly ARM) machines like the
Raspberry Pi.  And partly to teach myself how SDR works.  Working in
C, using fftw, doing graphics with a variety of methods for the
waterfall.

Mostly what I had in mind for documentation becoming obsolete was to
have the human  page author put a date in something when it's created.
That used to be in HTTP headers but wasn't very reliable because you'd
get the date it was last backed up or when it was pulled out of a
database.  I don't see it in this Firefox 70a1 (a nightly build) at
all.  A last edit date would also be good but a creation date would
put you in the ballpark.  I spent an hour or so following instructions
that turned out to be 9 years old.  I like old software in its place,
but not to try to mix with current stuff.


On 9/6/19, Vasil Velichkov <address@hidden> wrote:
> Hi Alan,
>
> On 06/09/2019 19.18, Alan Corey wrote:
>> It might help if I had more idea what's supposed to happen.
>
> The first command is suppose to print the list of directories your linker
> will look into when searching libraries. On my Fedora 29 x86_64 system it
> prints.
>
> $ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
> SEARCH_DIR("=/usr/x86_64-redhat-linux/lib64")
> SEARCH_DIR("=/usr/lib64")
> SEARCH_DIR("=/usr/local/lib64")
> SEARCH_DIR("=/lib64")
> SEARCH_DIR("=/usr/x86_64-redhat-linux/lib")
> SEARCH_DIR("=/usr/local/lib")
> SEARCH_DIR("=/lib")
> SEARCH_DIR("=/usr/lib")
>
> The second command is suppose to print all the commands used by "make" to
> build the library together with all their parameters.
>
>> Was I supposed to define SEARCH_DIR?
> No
>
> Or replace it?
>
> No
>
>> Is that 1 line or 2?
>
> 2 separate commands
>
>> Just running
>>  ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
>> ld: fatal error: no input files
>
> What ld version do you use and how did you install it?
>
> In case you are building with gcc run
>
> $ gcc -Xlinker --verbose  2>/dev/null | grep SEARCH | sed
> 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g'  | grep -vE '^$'
>
>> Trying as 1 line:
>> ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012 make VERBOSE=1
>> tr: extra operand ‘make’
>> Try 'tr --help' for more information.
>> ld: fatal error: no input files
>
> The two commands needs to be executed separately.
>
>>
>> From the stackoverflow example, if I put "-Wl,--verbose" in my
>> CMakeCache.txt as part of the string that gets passed to the C
>> compiler would that do it?
>
> I don't know.
>
>> If I could use a more normal -L and -l I'd
>> be more comfortable but I'm working through the full cmake process.  I
>> don't know how to extract what I need to try to link this manually.
>
>     make VERBOSE=1
>
> or
>
>     cd build/gr-fec
>     find . -name link*.txt
>     cat ./lib/CMakeFiles/gnuradio-fec.dir/link.txt
>
>> Yup, aarch64 on an Odroid N2:
>> Linux odroid 4.9.177+ #1 SMP PREEMPT Sat May 18 09:49:10 CEST 2019
>> aarch64 GNU/Linux
>>
>> Debian from meveric's image, still Stretch so far.  Some dependencies
>> I built from source, some are from the debs if they were new enough.
>
> ATM I don't have access to any ARM based systems but in Debian Testing
> container the output of ld commands is
>
> $ ld --version
> GNU ld (GNU Binutils for Debian) 2.32.51.20190821
>
> $ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
> SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
> SEARCH_DIR("=/lib/x86_64-linux-gnu")
> SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
> SEARCH_DIR("=/usr/lib/x86_64-linux-gnu64")
> SEARCH_DIR("=/usr/local/lib64")
> SEARCH_DIR("=/lib64")
> SEARCH_DIR("=/usr/lib64")
> SEARCH_DIR("=/usr/local/lib")
> SEARCH_DIR("=/lib")
> SEARCH_DIR("=/usr/lib")
> SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
> SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
>
> And the important part is that the output includes /usr/local/lib and
> /usr/local/lib/x86_64-linux-gnu
>
>> I disabled GR-WAVELET, FEC and GR-DTV, got it to build.  Ran
>> volk_profile, it picked up the neon correctly.  I don't have an RF
>> source driver so far.  Using an RTL2832 dongle, trying to build
>> Osmocom.
>
> See
> https://lists.gnu.org/archive/html/discuss-gnuradio/2019-09/msg00036.html
>
>> There's a ton of obsolete documentation out there.
>
> Please consider proposing documentation updates.
>
>> Probably doesn't matter but my LD_LIBRARY_PATH is
>> /usr/local/lib:/lib:/lib/aarch64-linux-gnu:/usr/lib:/usr/lib/aarch64-linux-gnu
>
> In my experience on most Linux distributions LD_LIBRARY_PATH and ldconfig
> cache are not used when building programs/libraries but only when running
> programs.
>
> Cheers,
> Vasil
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach