Hi,all
on 32-bit machine,i make a x86-64 toolchain using crosstool-0.43
I want to build a 64 bit helloworld application link libusb using toolchain
the libusb is download from ubuntu offical website(not built by my toolchain on purpose)

$ x86_64-unknown-linux-gnu-gcc -Iinclude -Llib -lusb main.c
lib/libusb.so: file not recognized: File format not recognized
$ lynn@lynn-oe-dev:~/temp$ ls include/
usb.h
$ lynn@lynn-oe-dev:~/temp$ ls lib/
libusb-0.1.so.4 libusb-0.1.so.4.4.4 libusb.so

$ file lib/libusb-0.1.so.4.4.4
lib/libusb-0.1.so.4.4.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

x86_64-unknown-linux-gnu-gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/lynn/project/crosscompile/crosstool-0.43/build/x86_64-unknown-linux-gnu/gcc-4.0.2-glibc-2.3.6/gcc-4.0.2/configure --target=x86_64-unknown-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/gcc-4.0.2-glibc-2.3.6/x86_64-unknown-linux-gnu --disable-multilib --with-sysroot=/opt/crosstool/gcc-4.0.2-glibc-2.3.6/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root --with-local-prefix=/opt/crosstool/gcc-4.0.2-glibc-2.3.6/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.0.2

Try compiling for 64 bit using the -m64 -fPIC flags

I need to know which files are responsible for telling getconf that my system is x86_64-slackware64-linux, not x86_64-unknown-linux-gnu.

checking build system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized

If I can't get this answered here, I will have to post it someplace else.

Edit: I just noticed that I have cpp as a file, not a link in /usr/bin/. Is cpp supposed to point somewhere else, or is that correct? Or is something else supposed to point to cpp?

Shingoshi

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090530 Shiretoko/3.5pre - Build ID: 20090530042121

You can find the solution in several of slackware64's SlackBuild scripts:

This would have to go right before the call to ./configure

Eric

Alien Bob,
Thank you! I will also forward this information on to someone else who specifically needs it as well. I knew something had to be wrong. I just couldn't figure out what it was. I really appreciated your help.

And no, I'm not kidding!
Thank You!!
Shingoshi

Ok. I have a question. And it's not meant to poke at anyone. It's just a question. Why is it that in the past, I had no problems building any applications on Slamd64 (which obviously is x86_64)? I've never even seen this before. And I've built a lot of applications. This is new to me. Has something changed in the way the compiler is (not) working? Does it have anything to do with how Slackware64 is configured itself? Is there some way to perform this operation (with a bash alias maybe) before every compile?

alias configure "cp -p /usr/share/libtool/config.{guess,sub} . && ./configure"

Shingoshi

Did you try to build this exact same application on Slamd64? If so, what happened there?

In general, compiling software for x86_64 (more specifically Slackware64 because that is what I compile on) will not display this problem. It was only in very rare cases that I had to mess with the program's original config.sub and config.guess files in the almost 1000 Slackware64 packages that I built before release.

Eric

I have gotten the same error on every attempted configure run in Slackware64. I always have x86_64-unknown-linux-gnu returned without fail. And I believe I have all of the required tools installed. I even went back to check to make sure. None of my toolchain is x86 ia32.

So would adding this to your bash profile fix this?
alias configure "cp -p /usr/share/libtool/config.{guess,sub} . && ./configure"

Shingoshi

And the thing that is really interesting, is that I used to build packages using Tukaani's tukbuild and Gilbert Ashley's src2pkg. Neither of them produced errors when building on Slamd64. So how is it that this is happening now? Someone mentioned a problem with Autoconf. Has that package changed from the functionality it used to provide?

Is there ever a situation where "cp -p /usr/share/libtool/config.{guess,sub} ." doesn't work? Can it ever actually be harmful in any way? If it is safe to always use that line without any issues, why can't a /etc/profile.d/configure.sh be created to provide an alias for configure as I have already described?

I would really like to have a global solution that works for all builds.

Shingoshi

You persevere in only listening at your own ramblings do you? Not just in the SLackware forum. Why don't you just try to anwer a helpful question? Yes, "x86_64-unknown-linux-gnu" works for a lot of other software. On slackware64.

Not that there will be any more help from me, the way you are spreading FUD against Slackware64 again after your week of having been banned from LQ.

Eric

I thought I did answer this question. But for the sake of clarity:
1.) I haven't run Slamd64 in a very long time.
2.) This isn't happening to only one application.
3.) I get this any time I run ./configure, for everything. Even when attempting to run it from the command line.
4.) I'm also getting this as well: configure: error: C compiler cannot create executables

For some reason whatever is responsible for setting the system environment for gcc, isn't working. I hope no one else has this same problem. Because they will have become collateral damage, and their systems also.

Shingoshi

Have you tried using ARCH=x86_64 ? This is required when compiling 32bit software on a multilib x86_64 system like Slamd64 and Slackware64. As I said, and I will repeat again, I have been compiling a lot of applications on Slackware64 and there will probably be 5 packages that are part of Slackware64, and none 3rd party, that had an issue with "machine `x86_64-unknown' not recognized".

I have no idea what the consequences were of installing these Bluewhite64 packages but you may experience a result of that action.

In that case, they have only you to blame, because of your stubbornness to prove to everybody that your solution is the only correct one.
Don't misinterpret me - your solution may work well for you, and I have no issues with that. If it works, use it. But if it works for you, that does not imply that it works for everyone else.

Eric

I greatly appreciate your comment about Bluewhite64's compatibility layer. I'm sorry to all for having been so defensive of my decision to use them. My point was simply that anyone should be free to try something that might work for them. But the overwhelming response has been, "no, you shouldn't do that. And it's obvious that no one who was objecting, had ever attempted to determine whether doing so would work. So for the most part, I was defending my right to try something others don't deem appropriate.

To answer any remaining questions here, readers should note this:
http://www.linuxquestions.org/questi...34#post3559534

Now continuing with the build issue.
1.) ARCH=x86_64: I'm not attempting to compile any 32-bit applications. I'm only attempting to compile for 64-bit. What I wind up with, are no packages being built at all, or empty packages.
2.) I'm also getting an error stating: configure: error: C compiler cannot create executables
Again. I'm getting this for everything (64-bit) I try to build. Along with another statement: You must run configure first.
3.) I'm still looking to see if this is MY FAULT! It's possible that it is. I had a gcc environment control which I created setup (while I was running Slackware 32-bit) in /etc/profile.d/gcc.sh which gave the following parameters:
gcc="-g -m32 pipe"
I had to do that in order to allow me compiling any sources on my system while running a 64-bit kernel. But once I upgraded to a 64-bit system, I removed that file.

Now what I'm not sure of is whether I have to go back now and explicitly state something else to get my system to be recognized as x86_64-slackware-linux. Can I now do something similar to declare TARGET=x86_64-slackware-linux somewhere in /etc? Or do I simply need to run "unset"? I've encountered that before, when building other things with a build.sh script. I think it was some self-contained build environment I was experimenting with. I don't remember which. I just know that I had to use unset. Now I remember. It was the L4Linux setup.

It takes me a while to wake up!! ;-)
Shingoshi

I will never deny people their right to make their own decisions. Nor the right to make their own mistakes (and learn from them).
What I try fight however (second nature perhaps, being a Slackware contributor, LQ regular and IRC channel operator) is people making claims about what is right and stuffing that through other people's throats. The harder you pushed, the harder I would push back.

Your problems do stem from a completely over-customized system that no longer bears any resemblance to a Slackware configuration, judging from what you describe here.

So, what if you just wipe your computer completely clean (keeping backups of /home /etc and /var/spool and other goodies) and install Slackware64 from scratch, then add 32bit compatibility packages on top? And then start building software? It would be interesting to see what results you get.

Eric

I may try building a completely new system. But this one is my communications link. I won't be touching this one, until I find out on another machine what the problem is. I can live for the time being, without building packages. And, I could always setup another chroot to build the packages I need.

Edit: I think I will go with using a chroot.

Thanks,
Shingoshi