ld error when gcc-compiling

[Masashi Nakane]

Hello,

I have installed gcc3.0 with swinstall.
The depot file was downloaded from
http://dsportal.eservices.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html
,which includes binutil_2.11.

And I compiled a source.
Then I got the error below,
$gcc -o hello hello.c
/usr/ccs/bin/ld: Unrecognized argument: +Accept
/usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld [options] [flags] files
collect2: ld returned 1 exit status
But,"gcc -c hello.c " works.

Should I install GNU ld?

[Stefan Farrelly]

gcc includes the linker (ld) so no need to install that separately.

Looks like a problem with the install or bundle or the compiler not looking in the correct place for the linker. Are you using the 64 or 32bit version ?

What source do you have for hello.c ?

[Stefan Farrelly]

Right, ive got the 64bit gcc3 installed and am ready to investigate your problem. Please explain it in as much detail as possible - exactly what you mean about aCC headers being included or not.

[Masashi Nakane]

The source is below,

#include
main()
{
printf("hello!\n");
}

I could compile the source with (Bundle)cc.
And No problem with the outputed excutable,
which says "hello!".

The system is 9000/800/A400-44 PA8500 with Hp-UX 11.0 .So I believe this is 64bit .

[Stefan Farrelly]

Ive deinstalled gcc 3.0 and installed 3.01 instead. Tried the same command;

gcc -o hello hello.c

And now I get;

as: warning 2: Unknown option "--traditional-format" ignored.
as: "/var/tmp/ccKMVjib.s", line 22: error 1052: Directive name not recognized - NSUBSPA

!!! Something is very strange here between gcc 3.0 and 3.01. The normal hp ANSI c compiler works fine.
Anyone know any more about this ?

[Stefan Farrelly · Accepted solution]

ive found the answer. You must install binutils separately. Download and install the latest version below and it fixes the compile problem!

http://hpux.connect.org.uk/hppd/hpux/Gnu/binutils-2.11.2/

[scott park_1]

I am having the exact same link problem:

gcc test.c -o test
/usr/ccs/bin/ld: Unrecognized argument: +Accept
/usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld [options] [flags] files
collect2: ld returned 1 exit status

Downloading/installing the latest binutils (which has an earlier date (07/25) than those installed with the gcc bundled (08/15)) makes things worse: I get the following error:

gcc test.c -o test
/var/tmp/ccOI1Cxg.s: Assembler messages:
/var/tmp/ccOI1Cxg.s:4: Error: Unknown pseudo-op: `.section'
/var/tmp/ccOI1Cxg.s:5: Fatal error: Not in a space.

[Masashi Nakane]

I finally gave up to make the download work
gcc3-64-bin.depot
from
http://dsportal.eservices.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html

And As Stefan says ,I tried the other depots
gcc-3.0.1-sd-11.00.depot
binutils-2.11.2-sd-11.00.depot

from
http://hpux.connect.org.uk/hppd/hpux/Gnu/

Then ,gcc works. Very happy!!!Thanks ,Stefan.

[scott park_1]

Yes, the

gcc-3.0.1-sd-11.00.depot
binutils-2.11.2-sd-11.00.depot

combo works. But is it 64-bit?

Here is my program:

#include

/******************************************************************************/
main(int argv, char *argc)
{
unsigned long wtf;
/*
* Print data
*/
printf("\nSizeof(unsigned long) = %d\n", sizeof(wtf));
}

and here is the output:

$ ./test

Sizeof(unsigned long) = 4

This seems to indicate that
"gcc-3.0.1-sd-11.00.depot" is a 32-bit compiler.

[Jessica Han]

This problem has come up in HP's opensource mailing-list (opensource@cup.hp.com)
There is a work around for the problem:
make a fake /opt/langtools/lib/pa20_64/crt0.o link to
/usr/ccs/lib/pa20_64/crt0.o
{ become root
mkdir -r /opt/langtools/lib/pa20_64
ln -s /usr/ccs/lib/pa20_64/crt0.o /opt/langtools/lib/pa20_64/crt0.o
}
Be aware that you need to remove the symoblic link if you want to install
HP C/aCC compilers in future.
We will fix this problem in the next release.

[Jeroen Ruigrok vd Werve_2]

FWIW, this still hasn't been fixed. But let me clarify a bit. Maybe I am seeing it wrong.

I installed the 3.0.2-64bit only depot and it all appears to work ok.

Compiling with -g requires /opt/langtools/lib[/pa20_64]/end.o, which is only available with the HP Compiler kits.

I found where the +Accept comes from.

It is normal practice nowadays to pass -Wl [linker options] to the compiler which in its turn passes it to the linker.

A common thing in GNU/GPL land is to do the following:

CC=gcc
${CC} -shared -Wl,-soname -Wl,libfoo.so.1.0 -o libfoo.so.1.0.0

The linker will get -soname, which it doesn't know and rejects, and then it gets the -Wl,libfoo, which causes it to come with the +Accept.

Try the following:

gcc -shared -Wl,l

which will illustrate the point.

The following will explain better what happens. [see attachment]

Weird where that +Accept comes from though in gcc's passing to the linker.

[Jeroen Ruigrok vd Werve_2]

Btw, FWIW, that workaround with the symlink doesn't seem to do anything at all.

Just a FYI.

Also, the depot files at the HPPA are 32-bit only last time I checked.

The ones you can download on the HP.com site are 32-bit and 64-bit and install in distinct directories.

[Jeroen Ruigrok vd Werve_2]

One step further,

from /usr/local/pa20_64/lib/gcc-lib/hppa64-hp-hpux11.00/3.0.2/specs

under *link: [around line 35]

You see:

+Accept TypeMismatch -E %{mlinker-opt:-O} %{!shared:-u main} %{static:-a archive} %{shared:-b}

Remove the "+Accept TypeMismath".

This will allow the commandline to display what it should've done in the first place:

[srv3008 B.11.00]root /tmp/soft/bzip2-1.0.1 # gcc -shared -Wl,l
/usr/ccs/bin/ld: Can't open l
/usr/ccs/bin/ld: No such file or directory

I'll see if I can hack the specs file some more to really work with this kind of behaviour people expect in their Makefiles.